Compatibility/Meetings/2017-09-work-week
Contents
- 1 webcompat Taipei Work Week
- 2 -webkit-appearance: whatever
- 2.1 Issue: explicit width on a input gets stretched out (to test if reproduces in new native fennec widget)
- 2.2 Issue: how do we deal with pages that are serving different -moz-/-webkit appearance values to deal with implementation quirks/differences?
- 2.3 TODO: Map out history of implementation attempts in Gecko.
- 2.4 Some preliminary tests in Chrome 63 DESKTOP:
- 3 Milestones Issues
- 4 Meeting followup for -webkit-appearance.
webcompat Taipei Work Week
This was a mini work week to make progress on Milestones issue. September 4th - 8th, 2017. Attendees: Eric, Karl, Mike We also worked on -webkit-appearance and a couple more issues. Eric scribed most of it.
-webkit-appearance: whatever
Bug 1352238 is almost done, what is the recommendation from our team to Jet/the layout team? https://bugzilla.mozilla.org/show_bug.cgi?id=1352238
There are interactions with CSS/HTML that we need to understand, for example background-image, for example:
- https://bugzilla.mozilla.org/show_bug.cgi?id=605985#c41
- https://github.com/whatwg/compat/issues/6#issuecomment-181715665
- https://n8finch.com/changing-select-menus-cross-browser-compatibility/
- https://www.chromestatus.com/feature/5668635896971264 (-webkit-appearance: none on HTMLMeterElement)
- https://github.com/webcompat/web-bugs/issues/3295#issuecomment-249768573 (background: 0, background: transparent)
- There are changes on the different widgets once we add a border for example, such as changing the background-color of the widget.
- https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/
- https://msdn.microsoft.com/en-us/library/dn793580(v=vs.85).aspx
- -webkit-appearance values from Microsoft's top sites crawler, as served to Chrome and Edge UAs (note, we left off values below 0.01%, because we presumably don't care about them).
- karl: I realized that depending on the element the values have different effects. Possibly we could write a script to generate output which would help test, create a matrix of elements.
- TODO: mike to figure out what Edge on mobile actually supports. And Desktop.
Values Chrome Edge none 33.8% 27.3% button 14.3% 22.6% textfield 4.2% 4.3% checkbox 0.292% 0.3% menulist-button 0.142% 0.148% menulist 0.115% 0.13% radio 0.108% 0.118% caret 0.062% 0.061% initial 0.029% 0.028% inherit 0.026% 0.027% listbox 0.01% 0.012%
Issue: explicit width on a input gets stretched out (to test if reproduces in new native fennec widget)
- https://github.com/whatwg/compat/issues/6#issuecomment-245503599 (this happens a lot)
- Fixed in Desktop here: https://bugzilla.mozilla.org/show_bug.cgi?id=605985#c50
Issue: how do we deal with pages that are serving different -moz-/-webkit appearance values to deal with implementation quirks/differences?
examples:
- https://webcompat.com/issues/1005#issuecomment-120774729 (for this one, if we supported -webkit-appearance: button, which one would win?
Opinion: We don't care about unprefixed appearance. Let's let the CSSWG solve that problem. (And appearance: none
is used in a lot of places because we told devs to do that).
Existing test pages to work from:
TODO: Map out history of implementation attempts in Gecko.
- Random Fact: Apple supports -apple-pay-button value: https://codepen.io/anon/pen/JyzyBK
- elements: input(all types) select textarea div span button meter img
- values: -webkit-appearance
- background stuffs: image, none, etc (for select case)
for el in elements: for val in values: el.style = "-webkit-appearance: {val}"
List of form elements: <button>
, <datalist>
, <fieldset>
, <input>
,<keygen>
, <label>
, <legend>
, <meter>
, <optgroup>
, <option>
, <output>
, <progress>
, <select>
, <textarea>
.
Codepen for the testing code https://codepen.io/webcompat/pen/qXvPBm
Mike's version: https://miketaylr.com/bzla/webkit-appearance.html
Some preliminary tests in Chrome 63 DESKTOP:
- button
- border changes the background
- webkit-appearance: none and webkit-appearance:button focus/active style are different (we may don't care)
- initial, inherit likes none (visually)
- checkbox, radio, menulist, menulist-button draws a widget, you can't activate them.
- square-button has a square-button style
- caret: flat design with no activity at all. textfield same behavior with a square border.
- div
- square-button, button clickable button
- checkbox, radio, menulist, menulist-button UI widget. checkbox, radio affects text layout
- img
- nothing different (Careful width and height have influences on some of the widgets.)
- input.type=button -you always get a button except for checkbox and radio
- menulist, menulist-button are empty. Maybe artifacts.
- input.type=checkbox
- only checkbox and radio, does something interesting. none makes it disappear.
- it shows when it has a width.
- input.type=color
- always there with different border/background
- input.type=date
- different style for border/background, except for radio/checkbox widgets. Everything else is functional.
- same for datetime-local
- same for month
- input.type=email -different style for border/background
- input.type=file
- all functional even checkbox and radio.
- input.type=image -subtle size differences
- input.type=password, number
- all functional, just background, border different
- input.type=radio
- only checkbox, radio are drawn. Checkbok doesn't looks like checkbox nor radio
- input.type=range
- range widget is drawn in all of them and is functional.
- input.type=reset
- always a button except for checkbox, radio
- input.type=search
- input.type=submit
- always there but checkbox, radio
- same as tel, text, time, url, week.
- meter
- draws the widget, except for none, initial, inherit
- output
- similar to div
- progress
- weird… all useless.
The only difference on Edge mobile.
- There's no effect for button, div, image, it doesn't understand anything.
- webkit-appearance: none on checkbox, radio suppresses the widget as well as initial, inherit
- They don't support textfield.
On Safari 10.0 iOS 10.3.3 (to check again in 9 days after new release of iOS)
- Quite different from Safari Desktop at first sight.
Milestones Issues
TODO:
- Simplify code status-*
- Track number of issues
- Free the label space for other use
- Issue open milestone: needstriage, needsdiagnosis, needscontact, contactready, sitewait
- Issue close milestone: wontfix, incomplete, invalid, fixed, duplicate, worksforme
Detail:
- Create issue->belong to one milestone (needstriage)
- Tests (Py + JS)
- API backend (Py)
- Webhooks (Py)
- Backbone (JS)
- Templates (CSS + HTML)
- Create a branch for milestone works
- Pull request against milestone branch
Issues:
- Keep milestone non-compat (close them all)
- Milestone !== for closed status, so we will have multiple closed milestones
- Close + move milestone in one click
- Cleaning status of issue with 2 status, no status
- Create milestone on test-repo, do the same thing on that first
- Move issues with label status to their own milestone without removing status-*
- Add milestone tests (keep labels for now, maybe remove status testing?)
Meeting followup for -webkit-appearance.
- Quick recap from miketaylr
- Stand version is not compatible with prefixed version for now. Maybe -moz/-webkit-appearance have different behaviors.
- More detail of implementing -webkit-appearance https://bugzilla.mozilla.org/show_bug.cgi?id=1368555
- Most common case: customize select, none to wipe everything, customize input range, etc