New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Groups split #14

Closed
darobin opened this Issue May 11, 2015 · 135 comments

Comments

Projects
None yet
@darobin
Member

darobin commented May 11, 2015

Just some thinking about a split somewhat different from Adrian's (but in keeping with his basic ideas). The proposal includes splitting HTML across the groups (as well as inside the groups).

  • Web Infrastructural Kernel. This needs to be the most boring WG ever created. It includes DOM, the eventing system and event loop, WebIDL, URL, anything related to public-script-coord, parsing HTML, MIME sniffing, Window, the core algorithms in the HTML specification (parsing attribute values and the such), the HTML DOM (History, Location...), Streams, the Browsing the Web section.
  • Markup & Interactivity. HTML overview specification, HTML best practices (anything that is now document conformance and the such), various specifications for attributes and elements of HTML, Web Components, Rendering HTML (default CSS and friends).
  • Platform Services. Storage and network APIs, Service Workers, Clipboard, Selection, Editing, Packaging, Manifest, IME, UI Events.
  • Web Media. EME, MSE, transcript, track binding, HTMLMediaElement, audio and video elements, possibly canvas.
@rubys

This comment has been minimized.

Show comment
Hide comment
@rubys

rubys May 11, 2015

Member

@darobin: I like your thinking. Can I ask your thoughts on what a "boring" URL spec would look like?

Member

rubys commented May 11, 2015

@darobin: I like your thinking. Can I ask your thoughts on what a "boring" URL spec would look like?

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin May 11, 2015

Member

@rubys: Don't take this the wrong way, but I think it's already boring enough to make the cut :) The background is this: if we call something "Web Core" (or anything like that that implies some sort of super-powerful fundamental group) we're setting ourselves up for people to try to push their pet ideas into the core (just like people instinctively don't like their specs being an extension spec of HTML, even though it makes no difference in terms of conformance).

My inspiration there is public-script-coord. Very boring name, lots of discussion about extremely important topics that are pretty much the opposite of glamorous. I think that's what we want for that group.

Member

darobin commented May 11, 2015

@rubys: Don't take this the wrong way, but I think it's already boring enough to make the cut :) The background is this: if we call something "Web Core" (or anything like that that implies some sort of super-powerful fundamental group) we're setting ourselves up for people to try to push their pet ideas into the core (just like people instinctively don't like their specs being an extension spec of HTML, even though it makes no difference in terms of conformance).

My inspiration there is public-script-coord. Very boring name, lots of discussion about extremely important topics that are pretty much the opposite of glamorous. I think that's what we want for that group.

@rubys

This comment has been minimized.

Show comment
Hide comment
@rubys

rubys May 11, 2015

Member

@rubys: Don't take this the wrong way, but I think it's already boring enough to make the cut :)

I'm not taking it the wrong way, but I will disagree with you. :-) And propose an alternative.

The current URL spec is very controversial in the IETF. It contains best practices and conformance criteria (things you are proposing splitting out of the core HTML spec). It contains things that no browser implements. Overall, browser vendors do not consider it a priority to address differences between what the spec says and what they implement. This is even true in cases where the spec and all other browser vendors agree.

If you take out all of this, what I see left is a definition of application/x-www-form-urlencoded and the URL APIUtils API (a.k.a., the URL object). That and perhaps something akin to the paragraphs that are currently in the HTML spec's reference section as an introduction.

I believe that these parts meet your criteria for being important and boring.

Member

rubys commented May 11, 2015

@rubys: Don't take this the wrong way, but I think it's already boring enough to make the cut :)

I'm not taking it the wrong way, but I will disagree with you. :-) And propose an alternative.

The current URL spec is very controversial in the IETF. It contains best practices and conformance criteria (things you are proposing splitting out of the core HTML spec). It contains things that no browser implements. Overall, browser vendors do not consider it a priority to address differences between what the spec says and what they implement. This is even true in cases where the spec and all other browser vendors agree.

If you take out all of this, what I see left is a definition of application/x-www-form-urlencoded and the URL APIUtils API (a.k.a., the URL object). That and perhaps something akin to the paragraphs that are currently in the HTML spec's reference section as an introduction.

I believe that these parts meet your criteria for being important and boring.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson May 11, 2015

Collaborator

@darobin

I like this structure. The grouping is simple, and the remit of each group seems reasonably clear.

Presumably accessibility would fall under the remit of the Markup & Interactivity group?

Collaborator

LJWatson commented May 11, 2015

@darobin

I like this structure. The grouping is simple, and the remit of each group seems reasonably clear.

Presumably accessibility would fall under the remit of the Markup & Interactivity group?

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 12, 2015

Member

@rubys, I don't think you're disagreeing with @darobin. The work in "Web Infrastructural Kernel" will be important, but that's not a reason for everyone to be part of that Group.

Member

plehegar commented May 12, 2015

@rubys, I don't think you're disagreeing with @darobin. The work in "Web Infrastructural Kernel" will be important, but that's not a reason for everyone to be part of that Group.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 12, 2015

Member

@darobin, canvas in Web Media seems out of place. Web Media should be about timed based media imho and canvas doesn't seem out of place there. I wonder if canvas can be handed over to SVG folks and/or if they'd be interested.

Member

plehegar commented May 12, 2015

@darobin, canvas in Web Media seems out of place. Web Media should be about timed based media imho and canvas doesn't seem out of place there. I wonder if canvas can be handed over to SVG folks and/or if they'd be interested.

@rubys

This comment has been minimized.

Show comment
Hide comment
@rubys

rubys May 12, 2015

Member

@plehegar: I'm not disagreeing with @darobin, but I don't think I've made my point clearly. Permit me to try again.

A while back, I noted that the split between WebApps and HTML sucked and suggested that they be merged.

@adrianba didn't disagree with me, but he took it further. Once you put all the specs into the same pile, he noted that you could then split them out into an order that made more sense.

@darobin didn't disagree with @adrianba, but noted that you didn't have to presume that the specs themselves had to remain as is: in particular the HTML spec has boring parts and contentious parts.

And this brings us full circle. I fully agree with @darobin, but would like to take his proposal further. He put URL in one WG, but I believe that it too has boring parts and contentious parts. @darobin and I would certainly agree on where the boring parts go. I'm not sure yet where the contentious parts should go, but the answer is certainly: "any place but Web Infrastructural Kernel". For now, I would suggest that the contentious parts go nowhere as addressing these issues does not appear to be a browser priority.

Clearer?

Member

rubys commented May 12, 2015

@plehegar: I'm not disagreeing with @darobin, but I don't think I've made my point clearly. Permit me to try again.

A while back, I noted that the split between WebApps and HTML sucked and suggested that they be merged.

@adrianba didn't disagree with me, but he took it further. Once you put all the specs into the same pile, he noted that you could then split them out into an order that made more sense.

@darobin didn't disagree with @adrianba, but noted that you didn't have to presume that the specs themselves had to remain as is: in particular the HTML spec has boring parts and contentious parts.

And this brings us full circle. I fully agree with @darobin, but would like to take his proposal further. He put URL in one WG, but I believe that it too has boring parts and contentious parts. @darobin and I would certainly agree on where the boring parts go. I'm not sure yet where the contentious parts should go, but the answer is certainly: "any place but Web Infrastructural Kernel". For now, I would suggest that the contentious parts go nowhere as addressing these issues does not appear to be a browser priority.

Clearer?

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin May 13, 2015

Member

I think that splitting URL into boring "how browsers process URLs", "best practices for URLs", "URL API" (or whatever similar lines make sense) is worth exploring. It's an idea that's come up before in order to make the various parties happ(y|ier).

Member

darobin commented May 13, 2015

I think that splitting URL into boring "how browsers process URLs", "best practices for URLs", "URL API" (or whatever similar lines make sense) is worth exploring. It's an idea that's come up before in order to make the various parties happ(y|ier).

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 15, 2015

Member

regarding the split of URL, I can't imagine splitting the URL work into different Groups and how it would fit with the split proposed by Robin. I have no concern with splitting the spec within the same Group.

Member

plehegar commented May 15, 2015

regarding the split of URL, I can't imagine splitting the URL work into different Groups and how it would fit with the split proposed by Robin. I have no concern with splitting the spec within the same Group.

@rubys

This comment has been minimized.

Show comment
Hide comment
@rubys

rubys May 15, 2015

Member

I can't imagine splitting the URL work into different Groups and how it would fit with the split proposed by Robin

I can. :-) Specifically:

  • "window.URL" goes into the same WG as "window.document"
  • "best practices for URLs" goes into the same WG as "HTML best practices".
Member

rubys commented May 15, 2015

I can't imagine splitting the URL work into different Groups and how it would fit with the split proposed by Robin

I can. :-) Specifically:

  • "window.URL" goes into the same WG as "window.document"
  • "best practices for URLs" goes into the same WG as "HTML best practices".
@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 19, 2015

Member

Here is an other alternative split:

  • Web Infrastructural Kernel. Includes HTML, DOM, Web Components, WebIDL, URL, anything related to public-script-coord, MIME sniffing
  • UI Core. Clipboard, Selection, Editing, IME, UI Events.
  • Platform Services. Storage and network APIs (Web Storage, IndexedDB, Fetch, XHR, Beacon), Service Workers, Packaging, Manifest, Streams
  • Web Timed Media. EME, MSE, transcript, track binding, HTMLMediaElement Core extensions, WebVTT, etc.

2DContext would be given to SVG Group.

Pros of this proposed split: doesn't separate the work of the DOM from its elements, doesn't make us wonder how to split the HTML spec.

Member

plehegar commented May 19, 2015

Here is an other alternative split:

  • Web Infrastructural Kernel. Includes HTML, DOM, Web Components, WebIDL, URL, anything related to public-script-coord, MIME sniffing
  • UI Core. Clipboard, Selection, Editing, IME, UI Events.
  • Platform Services. Storage and network APIs (Web Storage, IndexedDB, Fetch, XHR, Beacon), Service Workers, Packaging, Manifest, Streams
  • Web Timed Media. EME, MSE, transcript, track binding, HTMLMediaElement Core extensions, WebVTT, etc.

2DContext would be given to SVG Group.

Pros of this proposed split: doesn't separate the work of the DOM from its elements, doesn't make us wonder how to split the HTML spec.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson May 19, 2015

Collaborator

@plehegar
The UI Core group makes sense in some respects, but it feels a bit awkward to me. Things like HTML, Web Components etc. are also relevant to the UI, but they're grouped elsewhere.

Collaborator

LJWatson commented May 19, 2015

@plehegar
The UI Core group makes sense in some respects, but it feels a bit awkward to me. Things like HTML, Web Components etc. are also relevant to the UI, but they're grouped elsewhere.

@adrianba

This comment has been minimized.

Show comment
Hide comment
@adrianba

adrianba May 19, 2015

Collaborator

@LJWatson, the items proposed for "UI Core" revolve around a common theme of input/output interaction. Do you think the scope makes sense but has the wrong name or that the scope is troublesome too?

Collaborator

adrianba commented May 19, 2015

@LJWatson, the items proposed for "UI Core" revolve around a common theme of input/output interaction. Do you think the scope makes sense but has the wrong name or that the scope is troublesome too?

@adrianba adrianba referenced this issue May 19, 2015

Open

SVG? #3

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin May 20, 2015

Member

Reflecting a bit more on the HTML split, I think we don't have to make an agreement on the split as a pre-requirement for establishing the groups, but we should charter the groups in such a manner that they are allowed to take over parts of the HTML specification without rechartering.

Member

darobin commented May 20, 2015

Reflecting a bit more on the HTML split, I think we don't have to make an agreement on the split as a pre-requirement for establishing the groups, but we should charter the groups in such a manner that they are allowed to take over parts of the HTML specification without rechartering.

@richschwer

This comment has been minimized.

Show comment
Hide comment
@richschwer

richschwer May 20, 2015

Regarding Canvas 2D Context and moving to SVG, does 2D Context have enough industry uptake? I don't see a lot of work being done on it.

richschwer commented May 20, 2015

Regarding Canvas 2D Context and moving to SVG, does 2D Context have enough industry uptake? I don't see a lot of work being done on it.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres
Member

marcoscaceres commented May 20, 2015

@richschwer see: http://caniuse.com/#search=canvas (it's very well supported)

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson May 20, 2015

Collaborator

@adrianba

“the items proposed for "UI Core" revolve around a common theme of input/output interaction. Do you think the scope makes sense but has the wrong name or that the scope is troublesome too?”

The scope doesn’t feel right, but on further reflection it might be due to a different interpretation of “UI”.

If it’s user-interaction, the grouping suggested by @plehegar makes sense. If user-interface in the wider sense, then the split doesn’t work as well - because HTML and Web Components (at the least) feel as though they should fall under that definition.

Collaborator

LJWatson commented May 20, 2015

@adrianba

“the items proposed for "UI Core" revolve around a common theme of input/output interaction. Do you think the scope makes sense but has the wrong name or that the scope is troublesome too?”

The scope doesn’t feel right, but on further reflection it might be due to a different interpretation of “UI”.

If it’s user-interaction, the grouping suggested by @plehegar makes sense. If user-interface in the wider sense, then the split doesn’t work as well - because HTML and Web Components (at the least) feel as though they should fall under that definition.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson May 20, 2015

Collaborator

@darobin

How might that work? Wouldn’t the charters need to be reasonably clear about which deliverables were within a group’s remit?

Collaborator

LJWatson commented May 20, 2015

@darobin

How might that work? Wouldn’t the charters need to be reasonably clear about which deliverables were within a group’s remit?

@richschwer

This comment has been minimized.

Show comment
Hide comment
@richschwer

richschwer May 20, 2015

@marcoscaceres WebGL is an entirely different API than Canvas 2D. Is it being suggested that this be taken up by the SVG WG as well?
Also, I also see a LOT of gaps in IE support for Canvas 2D features. It appears that IE11 is not strategic for Microsoft so it would be good to see what is supported in Edge.

richschwer commented May 20, 2015

@marcoscaceres WebGL is an entirely different API than Canvas 2D. Is it being suggested that this be taken up by the SVG WG as well?
Also, I also see a LOT of gaps in IE support for Canvas 2D features. It appears that IE11 is not strategic for Microsoft so it would be good to see what is supported in Edge.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 20, 2015

Member

@marcoscaceres WebGL is an entirely different API than Canvas 2D. Is it being suggested that this be taken up by the SVG WG as well?

No. WebGL is handled by a different consortium (https://www.khronos.org/).

Also, I also see a LOT of gaps in IE support for Canvas 2D features. It appears that IE11 is not strategic for Microsoft so it would be good to see what is supported in Edge.

Edge support is also shown in the tables (just under IE11). Also, it's hyperbole to say there are a lot of gaps. IE11's support is on part with Gecko's (67%). That's not bad and I would expect it to get better over time (same with Gecko).

Member

marcoscaceres commented May 20, 2015

@marcoscaceres WebGL is an entirely different API than Canvas 2D. Is it being suggested that this be taken up by the SVG WG as well?

No. WebGL is handled by a different consortium (https://www.khronos.org/).

Also, I also see a LOT of gaps in IE support for Canvas 2D features. It appears that IE11 is not strategic for Microsoft so it would be good to see what is supported in Edge.

Edge support is also shown in the tables (just under IE11). Also, it's hyperbole to say there are a lot of gaps. IE11's support is on part with Gecko's (67%). That's not bad and I would expect it to get better over time (same with Gecko).

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 20, 2015

Member

@LJWatson re UI Core, yes, it would a User Interaction group.

Member

plehegar commented May 20, 2015

@LJWatson re UI Core, yes, it would a User Interaction group.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 20, 2015

Member

@darobin I believe writing charters in such a way that we can shuffle things around would be possible to a certain extend. If we define the scope properly, we can be more liberable on the set of deliverables. The AC has become less picky on scope/deliverables that it used to be. The best example is the 2014 CSS charter, that basically plenty of freedom to the CSS Working Group: "This list is not exclusive: The WG may also create new specifications, within its scope."
http://www.w3.org/Style/2014/css-charter

Member

plehegar commented May 20, 2015

@darobin I believe writing charters in such a way that we can shuffle things around would be possible to a certain extend. If we define the scope properly, we can be more liberable on the set of deliverables. The AC has become less picky on scope/deliverables that it used to be. The best example is the 2014 CSS charter, that basically plenty of freedom to the CSS Working Group: "This list is not exclusive: The WG may also create new specifications, within its scope."
http://www.w3.org/Style/2014/css-charter

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson May 20, 2015

Collaborator

@plehegar

Thanks for clarifying. That removes my concern about the grouping.

Collaborator

LJWatson commented May 20, 2015

@plehegar

Thanks for clarifying. That removes my concern about the grouping.

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin May 21, 2015

Member

@LJWatson @plehegar I was also thinking about the HTML-WebApps conduit which allowed for the transfer of deliverables from the former to the latter. It's been in place for years, I wouldn't expect an outcry against it.

@richschwer @marcoscaceres It's worth noting that @sideshowbarker and I were talking to someone on the Khronos board recently and they were very interested in setting up collaboration with graphics work at W3C. I certainly wouldn't expect SVG to take over WebGL, but if given 2DContext it would be a logical place to bring in Khronos as well.

Member

darobin commented May 21, 2015

@LJWatson @plehegar I was also thinking about the HTML-WebApps conduit which allowed for the transfer of deliverables from the former to the latter. It's been in place for years, I wouldn't expect an outcry against it.

@richschwer @marcoscaceres It's worth noting that @sideshowbarker and I were talking to someone on the Khronos board recently and they were very interested in setting up collaboration with graphics work at W3C. I certainly wouldn't expect SVG to take over WebGL, but if given 2DContext it would be a logical place to bring in Khronos as well.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson May 21, 2015

Collaborator

@darobin @plehegar

Good point. That conduit works, so no immediately obvious reason why it shouldn’t work in different circumstances.

Collaborator

LJWatson commented May 21, 2015

@darobin @plehegar

Good point. That conduit works, so no immediately obvious reason why it shouldn’t work in different circumstances.

@richschwer

This comment has been minimized.

Show comment
Hide comment
@richschwer

richschwer commented May 22, 2015

@darobin OK.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar May 23, 2015

Member

Some still see the idea of a split as a "W3C overhead". My next step on this front is to make sure we capture the rational (#18) and the motivations to justify a split of groups properly.

Member

plehegar commented May 23, 2015

Some still see the idea of a split as a "W3C overhead". My next step on this front is to make sure we capture the rational (#18) and the motivations to justify a split of groups properly.

@adrianba

This comment has been minimized.

Show comment
Hide comment
@adrianba

adrianba May 27, 2015

Collaborator

The AC has become less picky on scope/deliverables that it used to be.
@plehegar, at least from our perspective that is more that we're resigned to having failed at getting better charters. :)

I do think is important for groups is to have a good strong definition of scope, especially as we create a new structure. One thing to consider for deliverables outside the current HTML/WebApps set is to explicitly declare them in scope for the new group so people do the IPR review while not necessarily transferring the work immediately. This way, when the participants find an appropriate time to move, the group doesn't have to recharter. This is especially important if the number of these features is more than one or two.

Collaborator

adrianba commented May 27, 2015

The AC has become less picky on scope/deliverables that it used to be.
@plehegar, at least from our perspective that is more that we're resigned to having failed at getting better charters. :)

I do think is important for groups is to have a good strong definition of scope, especially as we create a new structure. One thing to consider for deliverables outside the current HTML/WebApps set is to explicitly declare them in scope for the new group so people do the IPR review while not necessarily transferring the work immediately. This way, when the participants find an appropriate time to move, the group doesn't have to recharter. This is especially important if the number of these features is more than one or two.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar Jun 12, 2015

Member

After several back-and-forth, the proposal is to merge the HTML and Web Applications Working Groups together, while creating a Media Working Group. Several reasons for doing so:

  • Documents like DOM and URL done in the HTMLWG came from WebApps originally. Web Components, seen as the next HTML big frontier, is currently in WebApps. The overlap between HTML and WebApps work has been there for several years (as proven by some of the current wordings in the HTML and WebApps charters).
  • Splitting HTML and WebApps groups would be too disruptive at this time and we probably wouldn't get the split right
  • HTML needs to be properly maintained and have a path for evolution, even if some may not see the need to evolve it substantially at the moment
  • Merging HTML and WebApps does keep the split option open while we're looking at splitting the HTML specification (see also https://lists.w3.org/Archives/Public/public-html/2015Jun/0009.html). We'd like to revisit this question next year. W3C is moving its workmode towards using github and the number of working groups may not make a difference in this move anyway (besides adding overhead).
  • the work of the media task force has been done in a separate task force and we need to properly ensure that the core media layer of Web is properly defined for the purpose of the Extensible Web. See a draft charter for this at http://w3c.github.io/charter-html/timed-media-wg.html .

The proposal will be to have those two Groups operating under the W3C Document and Software license for their deliverables:
http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document.html

Member

plehegar commented Jun 12, 2015

After several back-and-forth, the proposal is to merge the HTML and Web Applications Working Groups together, while creating a Media Working Group. Several reasons for doing so:

  • Documents like DOM and URL done in the HTMLWG came from WebApps originally. Web Components, seen as the next HTML big frontier, is currently in WebApps. The overlap between HTML and WebApps work has been there for several years (as proven by some of the current wordings in the HTML and WebApps charters).
  • Splitting HTML and WebApps groups would be too disruptive at this time and we probably wouldn't get the split right
  • HTML needs to be properly maintained and have a path for evolution, even if some may not see the need to evolve it substantially at the moment
  • Merging HTML and WebApps does keep the split option open while we're looking at splitting the HTML specification (see also https://lists.w3.org/Archives/Public/public-html/2015Jun/0009.html). We'd like to revisit this question next year. W3C is moving its workmode towards using github and the number of working groups may not make a difference in this move anyway (besides adding overhead).
  • the work of the media task force has been done in a separate task force and we need to properly ensure that the core media layer of Web is properly defined for the purpose of the Extensible Web. See a draft charter for this at http://w3c.github.io/charter-html/timed-media-wg.html .

The proposal will be to have those two Groups operating under the W3C Document and Software license for their deliverables:
http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document.html

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar Jun 12, 2015

Member

By "those two Groups", I do mean the merged HTML/WebApps one and the media one.

Member

plehegar commented Jun 12, 2015

By "those two Groups", I do mean the merged HTML/WebApps one and the media one.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar Jun 16, 2015

Member

We now have a draft charter for the merged HTML/WebApps group:
http://w3c.github.io/charter-html/group-charter.html
Ideas for a new name (ie other than WebApps) are welcome.

Member

plehegar commented Jun 16, 2015

We now have a draft charter for the merged HTML/WebApps group:
http://w3c.github.io/charter-html/group-charter.html
Ideas for a new name (ie other than WebApps) are welcome.

@silviapfeiffer

This comment has been minimized.

Show comment
Hide comment
@silviapfeiffer

silviapfeiffer Jun 16, 2015

Member

Maybe web client interfaces WG can work?

Member

silviapfeiffer commented Jun 16, 2015

Maybe web client interfaces WG can work?

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jun 17, 2015

Collaborator

@plehegar
"Ideas for a new name (ie other than WebApps) are welcome."

Throwing some ideas out (off the top of my head)...
Web Interfaces, Web Interface Technologies, Web Infrastructure, Web Infrastructures, Web Semantics and Structures, Web Semantics and Interfaces.

Failing that, I suppose "Web Stuff" would be out of the question!

Collaborator

LJWatson commented Jun 17, 2015

@plehegar
"Ideas for a new name (ie other than WebApps) are welcome."

Throwing some ideas out (off the top of my head)...
Web Interfaces, Web Interface Technologies, Web Infrastructure, Web Infrastructures, Web Semantics and Structures, Web Semantics and Interfaces.

Failing that, I suppose "Web Stuff" would be out of the question!

@wayneca

This comment has been minimized.

Show comment
Hide comment
@wayneca

wayneca Jun 17, 2015

Contributor

Web Platform WG?

Contributor

wayneca commented Jun 17, 2015

Web Platform WG?

@cwilso

This comment has been minimized.

Show comment
Hide comment
@cwilso

cwilso Jun 17, 2015

"Honey Pot WG". :P

On Wed, Jun 17, 2015 at 9:27 AM, Wayne Carr notifications@github.com
wrote:

Web Platform WG?


Reply to this email directly or view it on GitHub
#14 (comment).

cwilso commented Jun 17, 2015

"Honey Pot WG". :P

On Wed, Jun 17, 2015 at 9:27 AM, Wayne Carr notifications@github.com
wrote:

Web Platform WG?


Reply to this email directly or view it on GitHub
#14 (comment).

@adactio

This comment has been minimized.

Show comment
Hide comment

adactio commented Jun 18, 2015

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Jun 18, 2015

Contributor

Web Features Working Group?

Contributor

stevefaulkner commented Jun 18, 2015

Web Features Working Group?

@hober

This comment has been minimized.

Show comment
Hide comment
@hober

hober Jun 18, 2015

Member

So far, I like "Web Platform WG" the best.

Member

hober commented Jun 18, 2015

So far, I like "Web Platform WG" the best.

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jun 18, 2015

Member

I'm with @hober.

Member

darobin commented Jun 18, 2015

I'm with @hober.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 18, 2015

Member

/me tries to come up with a React Native joke and fails.... so yeah, Web Platform WG.

Member

marcoscaceres commented Jun 18, 2015

/me tries to come up with a React Native joke and fails.... so yeah, Web Platform WG.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar Jun 19, 2015

Member

I'm not a fan of Web Platform because of the honey pot risk but we may not be able to avoid in any case. So dc98f86 for now

Member

plehegar commented Jun 19, 2015

I'm not a fan of Web Platform because of the honey pot risk but we may not be able to avoid in any case. So dc98f86 for now

@silviapfeiffer

This comment has been minimized.

Show comment
Hide comment
@silviapfeiffer

silviapfeiffer Jun 19, 2015

Member

Web Core WG?

Member

silviapfeiffer commented Jun 19, 2015

Web Core WG?

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jun 19, 2015

Collaborator

I'm seriously not a fan of bikesheds (I was thinking Bikeshed Any Thing So HTML Is Timely, but couldn't be bothered reverse-engineering an acronymic for crazy).

Web Applications has been around as a name for a decade or so, and has apparently seemed clear enough to us, to WHATWG, and the universe. What's broken that we need to fix?

Collaborator

chaals commented Jun 19, 2015

I'm seriously not a fan of bikesheds (I was thinking Bikeshed Any Thing So HTML Is Timely, but couldn't be bothered reverse-engineering an acronymic for crazy).

Web Applications has been around as a name for a decade or so, and has apparently seemed clear enough to us, to WHATWG, and the universe. What's broken that we need to fix?

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jun 19, 2015

Collaborator

Although anything that has WC or WFM as an acronym works too.

Collaborator

chaals commented Jun 19, 2015

Although anything that has WC or WFM as an acronym works too.

@cwilso

This comment has been minimized.

Show comment
Hide comment
@cwilso

cwilso Jun 20, 2015

Web Technology Foundations Working Group. :P

"Web Core" is the least-best of all options, imo.

On Fri, Jun 19, 2015 at 3:52 PM, chaals notifications@github.com wrote:

Although anything that has WC or WFM as an acronym works too.


Reply to this email directly or view it on GitHub
#14 (comment).

cwilso commented Jun 20, 2015

Web Technology Foundations Working Group. :P

"Web Core" is the least-best of all options, imo.

On Fri, Jun 19, 2015 at 3:52 PM, chaals notifications@github.com wrote:

Although anything that has WC or WFM as an acronym works too.


Reply to this email directly or view it on GitHub
#14 (comment).

@AFBarstow

This comment has been minimized.

Show comment
Hide comment
@AFBarstow

AFBarstow Jun 20, 2015

Contributor

On 6/19/15 6:50 PM, chaals wrote:

I'm seriously not a fan of bikesheds (I was thinking Bikeshed Any
Thing So HTML Is Timely, but couldn't be bothered reverse-engineering
an acronymic for crazy).

So, I guess the following are out: "Web Hypertext Applications and Tags
WG" and "Browser Stuff WG" ;-)

Web Applications has been around as a name for a decade or so, and has
apparently seemed clear enough to us, to WHATWG, and the universe.
What's broken that we need to fix?

I agree with this sentiment, and have a relatively strong preference to
include "Web Applications" in the group's title, although appending
HTML would be fine too since the proposal is to literally create a "Web
Applications and HTML WG".

Contributor

AFBarstow commented Jun 20, 2015

On 6/19/15 6:50 PM, chaals wrote:

I'm seriously not a fan of bikesheds (I was thinking Bikeshed Any
Thing So HTML Is Timely, but couldn't be bothered reverse-engineering
an acronymic for crazy).

So, I guess the following are out: "Web Hypertext Applications and Tags
WG" and "Browser Stuff WG" ;-)

Web Applications has been around as a name for a decade or so, and has
apparently seemed clear enough to us, to WHATWG, and the universe.
What's broken that we need to fix?

I agree with this sentiment, and have a relatively strong preference to
include "Web Applications" in the group's title, although appending
HTML would be fine too since the proposal is to literally create a "Web
Applications and HTML WG".

@adactio

This comment has been minimized.

Show comment
Hide comment
@dwsinger

This comment has been minimized.

Show comment
Hide comment
@dwsinger

dwsinger Jun 21, 2015

On Jun 20, 2015, at 5:19 , Arthur Barstow notifications@github.com wrote:

On 6/19/15 6:50 PM, chaals wrote:

I'm seriously not a fan of bikesheds (I was thinking Bikeshed Any
Thing So HTML Is Timely, but couldn't be bothered reverse-engineering
an acronymic for crazy).

So, I guess the following are out: "Web Hypertext Applications and Tags
WG" and "Browser Stuff WG" ;-)

Web Applications and Platform (WAP)?

:-)

David Singer
Manager, Software Standards, Apple Inc.

dwsinger commented Jun 21, 2015

On Jun 20, 2015, at 5:19 , Arthur Barstow notifications@github.com wrote:

On 6/19/15 6:50 PM, chaals wrote:

I'm seriously not a fan of bikesheds (I was thinking Bikeshed Any
Thing So HTML Is Timely, but couldn't be bothered reverse-engineering
an acronymic for crazy).

So, I guess the following are out: "Web Hypertext Applications and Tags
WG" and "Browser Stuff WG" ;-)

Web Applications and Platform (WAP)?

:-)

David Singer
Manager, Software Standards, Apple Inc.

@dwsinger

This comment has been minimized.

Show comment
Hide comment
@dwsinger

dwsinger Jun 21, 2015

It’s quite commonly thought of as such, and indeed in many ways it supplied a platform for all sorts of things. So, perhaps you could explain as well as assert?

On Jun 20, 2015, at 20:20 , Jeremy Keith notifications@github.com wrote:

The web is not a platform.

David Singer
Manager, Software Standards, Apple Inc.

dwsinger commented Jun 21, 2015

It’s quite commonly thought of as such, and indeed in many ways it supplied a platform for all sorts of things. So, perhaps you could explain as well as assert?

On Jun 20, 2015, at 20:20 , Jeremy Keith notifications@github.com wrote:

The web is not a platform.

David Singer
Manager, Software Standards, Apple Inc.

@adactio

This comment has been minimized.

Show comment
Hide comment
@adactio

adactio Jun 21, 2015

David Singer wrote:

It’s quite commonly thought of as such, and indeed in many ways it supplied a platform for all sorts of things. So, perhaps you could explain as well as assert?

I did explain. The explanations can be found at the three hyperlinks I posted. Follow any (or all) of them for further explanation.

adactio commented Jun 21, 2015

David Singer wrote:

It’s quite commonly thought of as such, and indeed in many ways it supplied a platform for all sorts of things. So, perhaps you could explain as well as assert?

I did explain. The explanations can be found at the three hyperlinks I posted. Follow any (or all) of them for further explanation.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 21, 2015

Member

@adactio, you really are preaching to the converted. Your expectations of "platforms" don't appear the same as mine (and possibly others in this thread), which is understanding the web as a continuum of fault-tolerant technologies (which appears to be the overarching theme of the articles you pointed to, as also your position).

To call it "web spectrum" or "web continuum" or something other than "platform" would be academic at this point. The web is a platform that is capable of running on multiple platforms - which is unlike other platforms. However, it still requires APIs, new protocols, and other specified behavior to make it interoperable and to continue to provide value to both users and developers - just like other software platforms. I don't think anyone here has lost sight of the Web's original goals of universal access, or the separation between content, structure, and markup, etc. At the same time, declarative aspects of the web are sometimes overly constraining (or just simply bad and wrong) - which is why a lot of the work being done to progressively enhance the Web has been happening over the last few years (e.g., Service Workers, Web Manifest, Web Components, etc.).

Member

marcoscaceres commented Jun 21, 2015

@adactio, you really are preaching to the converted. Your expectations of "platforms" don't appear the same as mine (and possibly others in this thread), which is understanding the web as a continuum of fault-tolerant technologies (which appears to be the overarching theme of the articles you pointed to, as also your position).

To call it "web spectrum" or "web continuum" or something other than "platform" would be academic at this point. The web is a platform that is capable of running on multiple platforms - which is unlike other platforms. However, it still requires APIs, new protocols, and other specified behavior to make it interoperable and to continue to provide value to both users and developers - just like other software platforms. I don't think anyone here has lost sight of the Web's original goals of universal access, or the separation between content, structure, and markup, etc. At the same time, declarative aspects of the web are sometimes overly constraining (or just simply bad and wrong) - which is why a lot of the work being done to progressively enhance the Web has been happening over the last few years (e.g., Service Workers, Web Manifest, Web Components, etc.).

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jun 22, 2015

Member

@adactio Of course the Web is a platform; it is both a nice surface on which people can make stuff stand and the common policy of people who believe in a worldwide shared information space. This has nothing to do with whatever axe one may wish to grind about Web applications or whatever else. Even 25 years ago it was a hypertext publishing platform.

Member

darobin commented Jun 22, 2015

@adactio Of course the Web is a platform; it is both a nice surface on which people can make stuff stand and the common policy of people who believe in a worldwide shared information space. This has nothing to do with whatever axe one may wish to grind about Web applications or whatever else. Even 25 years ago it was a hypertext publishing platform.

@adactio

This comment has been minimized.

Show comment
Hide comment
@adactio

adactio Jun 22, 2015

@darobin Of course the Web is not a platform.

Weird—adding the words “of course” in there didn’t seem to have any noticeable effect.

Ah well, we’ll just agree to differ. But please do continue to characterise anyone who disagrees with your own viewpoint as “having an axe to grind”. That’s super-helpful.

adactio commented Jun 22, 2015

@darobin Of course the Web is not a platform.

Weird—adding the words “of course” in there didn’t seem to have any noticeable effect.

Ah well, we’ll just agree to differ. But please do continue to characterise anyone who disagrees with your own viewpoint as “having an axe to grind”. That’s super-helpful.

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jun 22, 2015

Member

@adactio Sure, I'm happy to just agree to disagree. It is, largely, terminology and in my honestly humble opinion where it isn't terminology I feel it is mostly a strawman. But FYI it's hard not to get an axe-to-grind impression from this:

axe

Member

darobin commented Jun 22, 2015

@adactio Sure, I'm happy to just agree to disagree. It is, largely, terminology and in my honestly humble opinion where it isn't terminology I feel it is mostly a strawman. But FYI it's hard not to get an axe-to-grind impression from this:

axe

@dwsinger

This comment has been minimized.

Show comment
Hide comment
@dwsinger

dwsinger Jun 22, 2015

On Jun 21, 2015, at 18:11 , Jeremy Keith notifications@github.com wrote:

David Singer wrote:

It’s quite commonly thought of as such, and indeed in many ways it supplied a platform for all sorts of things. So, perhaps you could explain as well as assert?

I did explain. The explanations can be found at the three hyperlinks I posted. Follow any (or all) of them for further explanation.

I am sorry, I should not have replied with jet-lag. I saw the repetition and underlining as both being some form of emphasis, whereas actually the underlining meant something else. My mistake, and apologies.

Nonetheless, I would disagree with what you say.

"And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.
The web is not a platform. It’s a continuum.”

Who says a platform has to have hard ‘edges’ and be perfectly uniformly implemented everywhere? I think that the last pair of sentences presents a false dichotomy.

Also, in the tension between native and web, the web is attractive in very large part in that it offers a platform which is widely implemented on a whole variety of systems. You want to be tightly integrated with, and optimized for, a specific system? — go native. You want broad deployability and system independence? — go to the web.

One can deploy a user experience, an ‘application’ in the general sense, as a web experience, and have it work across a significant range of systems and devices, without excessive testing of what system you’re actually on (with care and luck, and if you stay away from the latest or experimental features, with no system-sensitivity). That is a platform, in many people’s understanding — something that they can stand on, that is essentially ‘opaque’ and offers an abstraction you don’t have to look under.

I don’t think that only one layer, the OS plus it services gets to claim the ‘platform’ name — indeed, as you say, Flash can be a platform for some purposes — and that the broadly-deployed web specifications DO offer an important platform for a whole class of services and experiences.

David Singer
Manager, Software Standards, Apple Inc.

dwsinger commented Jun 22, 2015

On Jun 21, 2015, at 18:11 , Jeremy Keith notifications@github.com wrote:

David Singer wrote:

It’s quite commonly thought of as such, and indeed in many ways it supplied a platform for all sorts of things. So, perhaps you could explain as well as assert?

I did explain. The explanations can be found at the three hyperlinks I posted. Follow any (or all) of them for further explanation.

I am sorry, I should not have replied with jet-lag. I saw the repetition and underlining as both being some form of emphasis, whereas actually the underlining meant something else. My mistake, and apologies.

Nonetheless, I would disagree with what you say.

"And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.
The web is not a platform. It’s a continuum.”

Who says a platform has to have hard ‘edges’ and be perfectly uniformly implemented everywhere? I think that the last pair of sentences presents a false dichotomy.

Also, in the tension between native and web, the web is attractive in very large part in that it offers a platform which is widely implemented on a whole variety of systems. You want to be tightly integrated with, and optimized for, a specific system? — go native. You want broad deployability and system independence? — go to the web.

One can deploy a user experience, an ‘application’ in the general sense, as a web experience, and have it work across a significant range of systems and devices, without excessive testing of what system you’re actually on (with care and luck, and if you stay away from the latest or experimental features, with no system-sensitivity). That is a platform, in many people’s understanding — something that they can stand on, that is essentially ‘opaque’ and offers an abstraction you don’t have to look under.

I don’t think that only one layer, the OS plus it services gets to claim the ‘platform’ name — indeed, as you say, Flash can be a platform for some purposes — and that the broadly-deployed web specifications DO offer an important platform for a whole class of services and experiences.

David Singer
Manager, Software Standards, Apple Inc.

@plehegar

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar Jun 22, 2015

Member

@adactio I'm failing to understand your proposal if you have one. What exactly would you like to see done here?

Member

plehegar commented Jun 22, 2015

@adactio I'm failing to understand your proposal if you have one. What exactly would you like to see done here?

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jul 29, 2016

Collaborator

This issue seems to have been overtaken by events. Closing

Collaborator

chaals commented Jul 29, 2016

This issue seems to have been overtaken by events. Closing

@chaals chaals closed this Jul 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment