[whatwg] Fwd: Range.createContextualFragment in SVG contexts
(My apologies if you get this twice. I haven't seen my message on the public archives http://lists.w3.org/Archives/Public/public-whatwg-archive/, so I suspect that it was dropped.) On Sat, Dec 28, 2013 at 5:29 AM, Cameron McCormack c...@mcc.id.au wrote: Hi Victor, Victor Costan wrote: I'm trying to re-implement Range.createContextualFragment in Blink following this whatwg spec: http://domparsing.spec.whatwg.org/#extensions-to-the-range-interface There are two issues I'd like to discuss, related to the use of createContextualFragment in SVG contexts. 1) If a Range's context is ansvg element, I think the XML parsing algorithm should be selected, so the elements in the resulting DocumentFragment would get the SVG namespace. This way, inserting the fragment in ansvg tree would have the intended effect. Examples: https://bug711821.bugzilla.mozilla.org/attachment.cgi?id=582654 (the red circle should be completely covered by a black circle) https://codereview.chromium.org/115693010/diff/70001/ LayoutTests/fast/dom/Range/create-contextual-fragment- from-svg-element-range.html I think it would be unexpected that XML parsing is used here, when HTML parsing was used to get the SVG fragment in the document in the first place. Maybe the HTML fragment parsing algorithm should be changed to push the svg element on to the stack of open elements so that the parser will interpret the circle .../ as foreign content? Issues related to Range.createContextualFragment() in SVG contexts are starting to come up in bug reports: - https://bugzilla.mozilla.org/show_bug.cgi?id=1087715 - https://code.google.com/p/chromium/issues/detail?id=426400 Should Cameron's idea for changing the HTML fragment parsing algorithm be implemented? One other idea is to change the in body insertion mode spec so that there are 'A start tag whose tag name is one of: defs, g, svg' steps, but I personally think that Cameron's idea is much better. Daniel
Re: [whatwg] Fwd: Range.createContextualFragment in SVG contexts
On Tue, Oct 28, 2014 at 8:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 28, 2014 at 1:35 PM, Daniel Trebbien dtrebb...@gmail.com wrote: Issues related to Range.createContextualFragment() in SVG contexts are starting to come up in bug reports: - https://bugzilla.mozilla.org/show_bug.cgi?id=1087715 - https://code.google.com/p/chromium/issues/detail?id=426400 Should Cameron's idea for changing the HTML fragment parsing algorithm be implemented? Now Firefox' fragment parsing is fixed, it seems it behaves the same as Chrome. Not sure what's going on. I linked to the Firefox bug report mainly for context. Firefox' behavior seems correct now, and I can confirm that the modified jsFiddle http://jsfiddle.net/hfvz7srp/1/ is working correctly in Firefox Nightly 36.0a1 (2014-10-28). The issue that I am referring to is the behavior of Range.createContextualFragment() when the context node is not an SVG svg element, but some other SVG element such as an SVG defs or g element.
[whatwg] ARIA semantics of implied rows
Hi WHATWG, ยง4.9.12 Processing model ( https://html.spec.whatwg.org/multipage/tables.html#processing-model-3 ) currently states: A *row* is a complete set of slots from x=0 to x=x_width-1, for a particular value of y. Rows usually correspond to tr elements, though a row group can have some implied rows at the end in some cases involving cells spanning multiple rows. I am thinking that implied rows refers to cases such as: table id=theTable border=1 tbody tr td rowspan=10 colspan=3These are the first 10 rows./td /tr /tbody tbody tr tdRow 11, Column 1/td tdRow 11, Column 2/td tdRow 11, Column 3/td /tr tr tdRow 12, Column 1/td tdRow 12, Column 2/td tdRow 12, Column 3/td /tr tr tdRow 13, Column 1/td tdRow 13, Column 2/td tdRow 13, Column 3/td /tr tr tdRow 14, Column 1/td tdRow 14, Column 2/td tdRow 14, Column 3/td /tr tr tdRow 15, Column 1/td tdRow 15, Column 2/td tdRow 15, Column 3/td /tr /tbody /table .. where because the first row group has a TD spanning 10 rows but only one TR, there are 9 implied rows in that row group. As specified by WAI-ARIA 1.0: The HTML Working Group is incorporating WAI-ARIA into HTML 5. Official support for WAI-ARIA in HTML will be provided in that specification. This DTD is made available only as a bridging solution for applications requiring DTD validation but not using HTML 5. http://www.w3.org/TR/wai-aria/appendices#html_dtd One issue is that the ARIA semantics for implied rows are not defined. Currently, browsers that I have tested (Chrome 37.0.2062.124, Firefox 32.0.3, Safari 7.1, and Internet Explorer 11) only expose 6 rows for the example listed above. In order to get all 15 rows exposed to assistive technologies, I need to insert empty TR elements for the implied rows. It would be very useful if implied rows were exposed implicitly, using the same role as the row containing the anchor slot of the first cell in the implied row. Sincerely, Daniel Trebbien
Re: [whatwg] ARIA semantics of implied rows
(sorry, forgot to copy the list) On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: ... One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. WAI-ARIA does define roles for a table (grid, row, rowgroup, gridcell, etc.), but you can't specify the role and state attributes for HTML5 implied rows. I ran through the forming a table steps ( https://html.spec.whatwg.org/multipage/tables.html#forming-a-table ) on paper for the example and I came up with x_width is 3 and y_height is 15. If the table model has 3 columns and 15 rows (9 of which are implied), then browsers should expose 3 columns and 15 rows.
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 3:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien dtrebb...@gmail.com wrote: On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. No, HTML4 supported this; it probably didn't actually have any normative text around it, but browsers certainly supported having a rowspan go past the end of the explicit rows. That's true. Browsers supported this. What I mean is that HTML4 didn't have normative specification of this, but HTML5 does. I guess what I wanted to clarify is that when a browser exposes a table to the operating system's accessibility layer which screen readers use to announce the content of a web page, the model of the table in the accessibility layer should match the HTML5 table model. Using the Accessibility Inspector tool on Mac and the Inspect tool on Windows, I am seeing that browsers are currently not exposing the implied rows. Chrome, Firefox, Safari, and Internet Explorer are only exposing 6 rows for the example. Using the example table HTML in Chrome for Mac, Chrome is not exposing to Mac's accessibility hierarchy the 15 rows of the table, but only 6 rows; there are only 6 AXRow children of the AXTable. With Accessibility Inspector I see that the AXCell corresponding to the first cell in the first row has the AXColumnIndexRange attribute set to loc=0, len=3 and the AXRowIndexRange attribute set to loc=0, len=10 (which are correct). However, when I navigate to the Row 11, Column 1 cell, VoiceOver announces row 2 of 6 Row 11, Column 1. If I modify the example HTML to insert empty TR elements for each of the 9 implied rows: table id=theTable border=1 tbody tr td rowspan=10 colspan=3These are the first 10 rows./td /tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr /tbody tbody tr tdRow 11, Column 1/td tdRow 11, Column 2/td tdRow 11, Column 3/td /tr tr tdRow 12, Column 1/td tdRow 12, Column 2/td tdRow 12, Column 3/td /tr tr tdRow 13, Column 1/td tdRow 13, Column 2/td tdRow 13, Column 3/td /tr tr tdRow 14, Column 1/td tdRow 14, Column 2/td tdRow 14, Column 3/td /tr tr tdRow 15, Column 1/td tdRow 15, Column 2/td tdRow 15, Column 3/td /tr /tbody /table .. then when I navigate to the Row 11, Column 1 cell, VoiceOver announces row 11 of 15 Row 11, Column 1. Also, Chrome then exposes 15 AXRow children of the AXTable. Using the original example in Internet Explorer 11, IE11 is exposing only 6 rows like Chrome, Safari, and Firefox; with the Windows SDK Inspect tool, I see that the UIA_TableControlTypeId has the Grid.RowCount attribute set to 6. Switching on Narrator, when I navigate to the Row 11, Column 1 cell, Narrator announces Row 11, Column 1. Column 1 row 2 item. Using the modified HTML containing the 9 empty TR elements, the Grid.RowCount attribute is set to 15 and Narrator will announce Row 11, Column 1. Column 1 row 11 item for the Row 11, Column 1 cell. I am fairly certain that the model of the table that browsers expose to the accessibility layer should match the HTML5 table model, but I wanted to confirm. Also, I wanted to ask what the ARIA semantics of the implied rows are. For example, suppose I have this (admittedly contrived): table border=1 tbody tr aria-selected=true role=row td rowspan=5Spans 5/td tdnbsp;/td tdnbsp;/td tdnbsp;/td /tr tr aria-disabled=true role=presentation td rowspan=4Spans 4/td tdnbsp;/td tdnbsp;/td /tr tr aria-hidden=true role=row td rowspan=3Spans 3/td tdnbsp;/td /tr tr aria-busy=true role=presentation td rowspan=2Spans 2/td /tr /tbody /table There is 1 implied row in this example, but what are the ARIA state attributes of this implied row? Is it selected and/or disabled and/or hidden and/or busy? What is the implied row's role? There should probably be a requirement that ARIA roles and state should be consistent.
[whatwg] How to tell when a drag and drop was successful?
Reading through the spec, I am not seeing how an application can determine whether a drop into a different window was successful. Example use case: An app wants to take advantage of multiple screens, and so it opens two different windows which can be placed on different screens. The user can move items/tasks/events/objects/etc. from one window to another by dragging and dropping an item. The app sets effectAllowed to move in the source window and the dropEffect to move in the destination window on dragging over the area where the item is supposed to be dropped. The drag data are the essential details of the item that allow the destination window to know what was moved. The source window needs to know whether the drop was successful in order to decide whether to remove the item from the display in the source window. I have been experimenting with the attached HTML page in Chrome 28.0.1500.95 and Firefox 23.0 on Mac. I see no difference between the 'dragend' event object of a successful versus non-successful drop. The spec gives an example of removing the dragged element from the display: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#introduction-8 .. but this has the problem that the element is removed regardless of whether the drop was successful, right? One approach to removing the dragged element (as demonstrated by http://html5demos.com/drag ) is to do the cleanup on 'drop', but in a cross-window dragging scenario, the source window does not receive a 'drop' event. Daniel
