[Bug 25283] New: [Custom]: Custom element names should not end with a hyphen
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25283 Bug ID: 25283 Summary: [Custom]: Custom element names should not end with a hyphen Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: math...@qiwi.be QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 Custom element names must contain a hyphen, so e.g. `foo` is invalid, but `foo-bar` is valid. However, as per the current rules, e.g. `foo-` is valid too. IMHO it would make sense to tighten the requirement by disallowing trailing hyphens, thus making `foo-` invalid. -- You are receiving this mail because: You are on the CC list for the bug.
[testing] unstable tests: eventsource, workers, websockets, webmessaging, webstorage
James identified tests that aren't producing consistent results http://hoppipolla.co.uk/410/unstable.txt. For WebApps, the test suites indentified are: eventsource, workers, websockets, webmessaging and webstorage. Please review these tests and if needed, create an issue and/or submit a fix. -Thanks, AB Original Message Subject:Unstable tests Resent-Date:Tue, 25 Mar 2014 11:16:16 + Resent-From:public-test-in...@w3.org Date: Tue, 25 Mar 2014 11:15:51 + From: ext James Graham ja...@hoppipolla.co.uk To: public-test-in...@w3.org public-test-in...@w3.org Using data from a set of web-platform-tests runs in desktop Firefox, I have a list of tests that aren't producing consistent results. This data is based on 10 runs per platform for 5 different platforms (2 Linux, 3 OS X). Instability is considered per-platform (so a test that consistently produces one result on OSX and another on Linux is considered stable). The list of tests that produced unstable results in any configuration is at [1]. For the purposes of presentation I squashed the results down into a single list without platform information, but I can change that if needed. This set of tests represents about 2% of the top level test files in the repository. In order to use the testsuite in the Mozilla CI system (or in any other CI system), the rate of instability has to be much lower than that. Therefore it is necessary to determine why these tests are not giving consistent results and take appropriate action. In the best case the problems will be largely with the tests themselves, either doing something non-deterministic or just having too short a timeout, or whatever. In this case we need to fix the test. In some cases the instability may be due to non-determinism in Firefox, in which case I may (unfortunately) have to disable the test locally until the underlying issue is fixed. If you have any time to help investigate the issues with these tests, particularly for tests that you own (i.e. ones that you wrote), it would be much appreciated. [1] http://hoppipolla.co.uk/410/unstable.txt
[webcomponents]: The Shadow DOM Diaries
Folks, Over time, I've realized how difficult it is to trace decision points and the thought process in email archive and bug comments. So I started writing short(ish) articles to summarize and crystallize some of crucial bits. I called them the Shadow DOM Diaries: https://gist.github.com/dglazkov/efd2deec54f65aa86f2e I hope you find them helpful. Also hoping I will persist in growing and refining this novel, and eventually turn it into the movie. I am thinking Colin Firth as The Shadow DOM. :DG
[Gamepad] Future work
Hello, We've decided that the Gamepad spec is feature-complete at this point. We'll be doing some polish work to get it moving to last call status, but new features will be pushed out to a v.next. In light of this we've created a wiki page[1] to gather potential features for a future spec version. If you have ideas for additions to that list the best way to communicate them is to send mail to the list so we can discuss it. Thanks, -Ted 1. https://www.w3.org/wiki/Webapps/GamepadFeatures
[Bug 24632] [meta][imports]: The spec should have fewer monkey patches
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24632 Bug 24632 depends on bug 24637, which changed state. Bug 24637 Summary: [imports] style sheet that is blocking scripts should be generalized to support HTML Imports https://www.w3.org/Bugs/Public/show_bug.cgi?id=24637 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24349] [imports]: Import documents should always be in no-quirks mode
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349 Bug 24349 depends on bug 24667, which changed state. Bug 24667 Summary: Want an quirks mode override for HTML parser https://www.w3.org/Bugs/Public/show_bug.cgi?id=24667 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER -- You are receiving this mail because: You are on the CC list for the bug.
Re: Should events be preferably sent to the Window or the nearest object?
On Mon, 7 Apr 2014, Marcos Caceres wrote: On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote: Agreed. The exact target isn't very important here, and so being consistent with legacy event firing for the same system is probably a good idea. Agree. Let's go with consistency, even though it feels a bit weird. Ian, would it be possible to have some kind of hook in HTML to give us this behaviour for free? That is, given an event handler IDL attribute on some interface, we get the HTML attribute equivalent on body element (all wired up and ready to be used). That would be useful in that we wouldn't need to define the HTML onorientationchange attribute in the Orientation Lock spec (and all future specs). This could really help with consistency. I'm very happy to add any such attributes to the HTML spec, just file a bug once you're confident that it won't change. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
After working with developers inside and outside Microsoft, it seems there
are several types of paste that make sense in various scenarios. For
instance,
1- if pasting into a rich document, it could be important to maintain
source styling information.
2- When pasting into a wiki from an external source, it might make more
sense to maintain destination styling instead.
3- When copying from a wiki and pasting back into that same wiki, it makes
sense to maintain any special formatting on that text (inline styles) but
otherwise to use the theme (style sheets).
There is one other scenario here, which is to maintain the html shape, but not
any styles.
4- When seeking to maintain lists and tables, but format them with destination
styles, it makes sense to remove style elements and style rules, but keep other
html ( li and table for instance ).
One possibility would be to do something similar to Firefox, but also
include a text/css clipboard item, which contains styles relevant to
what is copied
How hard do you think this is to implement?
Thanks for the code sample and thoughts! I'll run it by a few more
developers to get deeper insight and get back to you.
Great! Note that the code samples are just to get us started thinking about
the issues we'll have to tackle if we're going to do this - if some other
behaviour (say,
creating new class names and making up a new style sheet with
generated/computed styles) is easier to implement or seems to make more sense
by all means
suggest that other behaviour instead.
In order to support the 4 scenarios I mentioned above, we need to be able to
distinguish inline css from style sheets. Your idea here about creating a new
style sheet seems like a good way to go since it helps solve the selectors
problem where css doesn't work the same once you remove the context by copying
a section out, and it keeps the inline styles separate from the style sheets.
We could include this styles in the head of the document or in a new text/css
item.
On copy, we would take something like Chrome's algorithm to get relevant css
for each element. For top-level elements, this would mean several rules by
default to 'reset' the style, and anything other relevant styles. We would
create a new class for each unique set of computed styles and give it a name
that can be recognized and unique, maybe copiedStyle_randomid where
randomid is a guid or similar. We would also remove any inline style elements
like Chrome/Firefox already do. So on copy you would get something like this on
the clipboard:
Version:0.9
StartHTML:000157
EndHTML:03
StartFragment:01
EndFragment:02
SourceURL:http://en.wikipedia.org/wiki/Darth_vader
html
head
style
.copiedStyle_12345 {
color: black; background-image: none; font-weight: normal; margin: 0px
0px 0.25em; overflow: hidden; padding: 0px; border-bottom-width: 1px;
border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170); font-size:
1.8em; line-height: 1.3; font-family: 'Linux Libertine', Georgia, Times, serif;
font-style: normal; font-variant: normal; letter-spacing: normal; orphans:
auto; text-align: start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-position: initial initial; background-repeat: initial initial;
}
/style
/head
body
!--StartFragment--h1 id=firstHeading class=copiedStyle_12345
firstHeading lang=enspan dir=autoDarth
Vader/span/h1!--EndFragment--
/body
/html
Then during copy, the text/html element would return all of this data (or the
style would be in text/css instead). My devs believe having one text/html item
(instead of text/css) would make it easier to get an element (by document.write
for instance) that could be used with querySelector etc. Then javascript could
handle scenarios 2-4 above easily by keeping or removing inline styles and
elements, and 1 above could be done by calling querySelectorAll for each
copiedStyle_* class and inlining those styles like Chrome does by default.
Other style classes (like 'firstHeading' here) can be kept so that if you paste
back into the same page, they apply again and you don't need to inline anything.
This means copy works like firefox + new classes to track styles that Chrome
would currently inline. Paste works like Chrome (the text/html item returns all
of the clipboard's html text). End to end, we enable the major scenarios we
have identified of for copy/paste.
Ultimately I believe the goal of this feature is just to enable functionality
in an interoperable way. To make it easier to use, js frameworks could make a
document object available (instead of plain text), or provide functions to
accomplish 1-4 (and other paste types). Thoughts?
[webcomponents] HTML Imports notes
Hi, Since last HTML Imports WD is published, I heard some feedback. Most of them are about the loading order and its sync/async nature. Thanks for sharing your thought! At the same time, I found there are some confusion about how it works. As it's hard for me to capture the underlying thinking in the standard document, I thought that it might be helpful to informally sketch what's behind the current design and what we're thinking. So here it is [1]. I hope this clarifies some of your questions and/or concerns. If you have any comments, let's talk at coming F2F. Bests, [1] https://gist.github.com/omo/9986103 -- morrita
Re: [webcomponents]: The Shadow DOM Diaries
I intentionally tried to keep these articles conversational, and based on thought experiments and simplified use cases, but I totally see a value in coming up with a coherent timeline of events/decisions that deep-links into public-webapps and bugzilla. I've been working on that, but have nothing to show for yet. I am slow. :DG On Mon, Apr 7, 2014 at 3:40 PM, Ryosuke Niwa rn...@apple.com wrote: This is great! Thanks for writing this up. Is it possible to have references to relevant mailing list and Bugzilla discussions? While summarizing the discussion so great, having hyperlinks to relevant email threads will help bootstrap newcomers get up to speed if they wanted to give feedback on public-webapps and Bugzilla. - R. Niwa On Apr 7, 2014, at 11:52 AM, Dimitri Glazkov dglaz...@google.com wrote: Folks, Over time, I've realized how difficult it is to trace decision points and the thought process in email archive and bug comments. So I started writing short(ish) articles to summarize and crystallize some of crucial bits. I called them the Shadow DOM Diaries: https://gist.github.com/dglazkov/efd2deec54f65aa86f2e I hope you find them helpful. Also hoping I will persist in growing and refining this novel, and eventually turn it into the movie. I am thinking Colin Firth as The Shadow DOM. :DG
Re: [testing] Proposal: close public-webapps-testsuite
Sounds like a great plan to me. I'm not sure automatically forwarding emails to public-webapps is a great fallback. It might be spammy for us. I think an auto-reply with references to testing infra. mailing list would be better. - R. Niwa On Apr 2, 2014, at 5:39 AM, Arthur Barstow art.bars...@nokia.com wrote: [ Bcc: public-test-infra; Advanced apologies for the cross-posting ] Hi All, WebApps created the [public-webapps-testsuite] (p-w-ts) list when the group's testing effort was centralized in hg/webapps/. Since then, the group adopted Github and [w-p-t] for its testing and all relevant discussions about testing infrastructure are conducted on [public-test-infra] (p-t-i) and in [#testing]. Although p-w-ts used to have a low to moderate level of e-mail, the list has effectively become obsoleted by the GH workflow and notifications about important changes in the infrastructure that are relevant to WebApps are not sent to p-w-ts. Consequently, I propose: 1. public-webapps-testsuite be closed (the archive will of course remain) 2. All e-mail sent to p-w-ts will automatically be forwarded to public-webapps. Another option is to automatically reply to the sender and tell them: p-w-ts is closed and to re-send their e-mail to public-webapps. 3. In the event there is a need to discuss one of WebApps' test suites, use the public-webapps list. Any comments or objections to the above? I support #1 and am indifferent about the options in #2 although W3C's SysTeam recommends the later option which seems fine by me. BTW, of the ~50 people subscribed to p-w-ts, almost half of them are also subscribed to p-t-i. Regardless of whether or not this proposal passes, if you want to follow W3C's testing effort I strongly recommend you subscribe to p-t-i. -Thanks, AB [public-webapps-testsuite] http://lists.w3.org/Archives/Public/public-webapps-testsuite/ [public-test-infra] http://lists.w3.org/Archives/Public/public-test-infra/ [w-p-t] https://github.com/w3c/web-platform-tests [#testing] http://krijnhoetmer.nl/irc-logs/testing/ Original Message Subject:ACTION-713: If systeam can autoforward p-w-testsuite to p-test-infra, close p-w-ts (Web Applications Working Group) Date:Tue, 1 Apr 2014 14:33:36 + From:ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To:Web Applications Working Group public-webapps@w3.org To:art.bars...@nokia.com ACTION-713: If systeam can autoforward p-w-testsuite to p-test-infra, close p-w-ts (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/713 On: Arthur Barstow Due: 2014-04-08 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Re: Should events be preferably sent to the Window or the nearest object?
On Tue, 8 Apr 2014, at 8:37, Ian Hickson wrote: On Mon, 7 Apr 2014, Marcos Caceres wrote: On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote: Agreed. The exact target isn't very important here, and so being consistent with legacy event firing for the same system is probably a good idea. Agree. Let's go with consistency, even though it feels a bit weird. Ian, would it be possible to have some kind of hook in HTML to give us this behaviour for free? That is, given an event handler IDL attribute on some interface, we get the HTML attribute equivalent on body element (all wired up and ready to be used). That would be useful in that we wouldn't need to define the HTML onorientationchange attribute in the Orientation Lock spec (and all future specs). This could really help with consistency. I'm very happy to add any such attributes to the HTML spec, just file a bug once you're confident that it won't change. When we will be in LC and close to CR, I will file a bug to remove the monkey patching I am doing on the HTML spec. -- Mounir
[Bug 21992] Consider adding .inputMethodContext to SVGElement
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21992 Takayoshi Kochi ko...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER --- Comment #5 from Takayoshi Kochi ko...@google.com --- Somebody will revisit this once this is required for a useful purpose. -- You are receiving this mail because: You are on the CC list for the bug.
