Closed SachaG closed 1 year ago
Or, a more generic approach could be to define a regexp for :stuck
that also requires matching against sticky
in the same freeform textfield. So the word sticky
would "belong" to the :stuck
feature, and not be matched by the position: sticky
feature.
In fact that might already be possible without any further code changes, I have to check…
So this seems to work. I added this regex to the :stuck
feature:
position(:| |: )?sticky(.*?)stuck|stuck (.*?)position(:| |: )?sticky
This matches anything between position:sticky
and stuck
; or stuck
and position:sticky
, including both bounds. So even if position: sticky
is then matched it will be discarded because it's being matched inside a longer matched string (same logic behind how we match "React Native" for React Native and not for React).
How should we handle a freeform input such as:
Matching
position:sticky
is misleading, because in the case of the "what features are missing from CSS" question that's not the feature that the respondent thinks is missing.So I'm thinking that the
stuck
entity could define an "override", in other words wheneverstuck
is matched in a string, thenposition: sticky
cannot also be matched, and that token would then simply not be included in the dataset.Is this a good idea? Are there other cases where it would be applicable? Or is it better to report counts for both
position: sticky
andstuck
, and let readers figure it out?