This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html Multipage: http://www.whatwg.org/C#the-indicated-part-of-the-document Complete: http://www.whatwg.org/c#the-indicated-part-of-the-document Comment: Define the "top of the document" in a semantic way. Posted from: 114.43.115.138 by kennyluck@csail.mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
For two cases: 1. Vertical writing (IE9 scrolls a document in vertical writing to the before side, WebKit always the top side.) 2. Screen readers I would hope we just remove #top though, if that doesn't break sites.
#top is used by half the Web. I don't really understand what's unambiguous about "top of the document". Can you elaborate?
(In reply to comment #2) > #top is used by half the Web. > > I don't really understand what's unambiguous about "top of the document". Can > you elaborate? The non-interoperability as described in comment 1 (vertical writing). But if you feel like the best way to resolve this is to file a bug then feel free to WONTFIX this. Am I right that you assume IE9 is right and WebKit is wrong? I can't quite tell that from the prose but I assume the "before" side is more of a natural interpretation?
This bug was cloned to create bug 18244 as part of operation convergence.
Do you have a testcase showing what you mean? I'm not really understanding the problem here. Vertical text isn't properly specced yet, is it?
Created attachment 1187 [details] #top and vertical writing
(In reply to comment #5) > Do you have a testcase showing what you mean? Here you go. (I have no idea why the attachment prompts for download...) > I'm not really understanding the problem here. In WebKit, if you click the link, the window scrolls to the physical top. In IE, it scrolls to the logical before-start side (beginning of the document). The spec seems to indicate WebKit is right, and I am just slightly opposed to that. For what it's worth, in Firefox and Opera, the window scrolls to the top-start, observing 'direction' (you need to tweak the attached test case a bit), which seems more "semantic" (beginning of the document). > Vertical text isn't properly specced yet, is it? I don't think that's relevant. It's just a matter of whether #top is semantic or not.
Where you scroll to when scrolling to the top of the document is a CSSOM issue, I'd say. Not sure how to fix this.
Right now the spec relies on: http://dev.w3.org/csswg/cssom-view/#element-scrolling-members ...which says to use the top left. But it doesn't really handle the "top of the document" concept.
zcorpan, this may be relevant to your new interests
(In reply to comment #1) > For two cases: > > 1. Vertical writing (IE9 scrolls a document in vertical writing to the > before side, WebKit always the top side.) Actually WebKit scrolls to the bottom if the attached test case is modified with <html dir=rtl>. It seems to not scroll in the other direction at all. I have specified that the appropriate corner be scrolled to. HTML needs to hook in to 'beginning of the document', though. https://dvcs.w3.org/hg/csswg/rev/6102bc601fb4 > 2. Screen readers I haven't specified anything for this. I'm not sure CSSOM View is the right place to define what to do.
I'll hook into "beginning of the document". Thanks!
Currently the HTML spec invokes "scroll an element into view" with the "top of the document" which is bogus since that's not an element. Instead, for the #top case, invoke http://dev.w3.org/csswg/cssom-view/#scroll-to-the-beginning-of-the-document
Checked in as WHATWG revision r7979. Check-in comment: Finally clean up how we scroll to the top of a document http://html5.org/tools/web-apps-tracker?from=7978&to=7979