Deter use of this kind of anchors instead of id-based anchors

[KOLANICH]

It is proposed to make this kind of links unworkable for the content within the same page.

Rationale: code-monkeys would abuse it for referencing content in own applications instead of ids. It can cause performance, efficiency and resource consumption problems. But code-monkeys don't care. Unfortunately sometimes even large web resources hire code-monkeys. So the standard should be foolproof.

[dead-claudia]

You can't select these anyways unless you do a seriously complicated, slightly arcane CSS selector (which is itself a bit inaccessible to code monkeys), and with my proposal, it takes away even that. And for text search, it's not that substantially slower, not enough that abuse like this really generates a substantial performance problem outside larger pages that are already relatively slow to load in the first place.

Edit: Forgot to finish and link my proposal before commenting.

[bokand]

I'm not sure I understand the issue here. Is the proposal to disallow scroll-to-text fragments on a navigation within the same document (e.g. window.hash = '...'), the existing proposal already does so in the Security section, the Limit feature to full (non-same-page) navigations bit of the Security section

[bokand]

I'm also curious what the performance and resource consumption problems would be. Doing a text search over a file does a little more work but is trivial in comparison to loading and processing the full resource so I don't think that's a concern.

[KOLANICH]

Is the proposal to disallow scroll-to-text fragments on a navigation within the same document (e.g. window.hash = '...'), the existing proposal already does so in the Security section, the Limit feature to full (non-same-page) navigations bit of the Security section

Indeed; thanks.

I'm also curious what the performance and resource consumption problems would be. Doing a text search over a file does a little more work

The problem is that locating content by textContent is more expensive than locating an element by id. So the losses are (cost of STTF - cost of scrolling to element located by id) * count of abuses, where an abuse is using STTF istead of scrolling to id or name where there is almost no difference. If we want to minimize the losses, we either want to minimize the delta or minimize the count of abuses.

but is trivial in comparison to loading and processing the full resource so I don't think that's a concern.

in order to scroll browser has to parse the source and determine bounding boxes of pieces of content anyway, doesn't it?

[dead-claudia]

@KOLANICH

in order to scroll browser has to parse the source and determine bounding boxes of pieces of content anyway, doesn't it?

Try searching for mathtt in this page full of LaTeX. In Chrome, I get two results: one is visible and the other is not. The browser doesn't try to account for bounding boxes during page search, only display and visibility. If you want to compare all three means of hiding content, check this out. When I try that in Chrome, I get this:

CSS	Searchable
No styles	Yes
display: none	No
visibility: hidden	No
opacity: 0	Yes

So it needs a quick CSS pass, but it does not need to calculate layout. In fact, it only needs to calculate two CSS properties, neither of which are inherited.

Also, it's worth noting in this case, your cursor will turn into a text select cursor over the opacity: 0 and unstyled spans, but it remains a general purpose pointer over the display: none and visibility: hidden spans.

[bokand]

The browser only has to walk the laid-out DOM tree. Depending on the implementation, it may have to do that anyway for an id match.

I just mean that by the time the page has been downloaded, parsed, run style, layout, paint, etc. the cost of doing a text search is negligible in comparison. The amount of work the browser is doing to load any given page is quite staggering.