Re: [webkit-dev] ChangeLog Deprecation in WebKit
Hello Jonathan, Probably you are aware of that but https://github.com/WebKit/WebKit#contribute / https://webkit.org/contributing-code/ still mentions the ChangeLogs and old workflow. Le 16/05/2022 à 22:46, Jonathan Bedard via webkit-dev a écrit : Starting tomorrow, Tuesday May 17th, WebKit will no longer be using ChangeLogs and will instead require commit messages in new commits. These were the norm when we started the project, but now they are unusual, antiquated, and get in the way of common git tooling. This means that we need a commit message in every patch or PR that's submitted for review. From prior discussion, it is very clear that there are legitimate downsides too, and I want to take this opportunity to suggest recommended paths forward. You will need to take action if you: - Have a pure-Subversion checkout - Draft patches without making local commits - Draft patches from multiple local commits - Have patches with ChangeLogs already in bugzilla - Have pull requests with ChangeLogs https://github.com/WebKit/WebKit/wiki/Migration covers migration to GitHub workflows in general, but Tuesday’s change is quite a bit more narrow in its effects. Below I’ve listed the actions you may need to take - Have a pure-Subversion checkout Follow https://github.com/WebKit/WebKit/wiki/Migration#subversion to clone github.com/WebKit/WebKit <http://github.com/WebKit/WebKit> and start developing from a GitHub checkout. The patch workflow works just as well from a GitHub checkout. One significant difference is that it's not possible to commit directly, but this is going away soon as GitHub becomes the source of truth, so it is probably not worth migrating to git-svn for. Also, some people find git-svn handy to convert between revision formats; we have `git webkit find` as a replacement. - Draft patches without making local commits Run `git-webkit setup` to configure your local git hooks to provide a WebKit commit-message template. Before running `webkit-patch upload`, run `git commit -a` to create a local commit with all local changes. To amend that commit, run `git commit -a —amend`. - Draft patches from multiple local commits EWS will test patches with multiple commits in them, but Commit-Queue will not land those patches. If you have a multi-commit patch (or branch) applied locally, you need to squash them. I’d recommend `git rebase -i `. To do this, run `git rebase -i HEAD~3`, git will then open your editor and offer to `pick` the last 3 commits. Keep `pick` for the first listed commit, but use `squash` for the other two and close your editor, the last 3 commits will be squashed into a single commit. - Have patches with ChangeLogs Apply your patch with `webkit-patch apply-from-bug `. If we’ve already removed the ChangeLog files from the repository, this patch application will fail. Resolve the conflicts, and commit your local changes and draft a commit message. If we haven’t yet removed the ChangeLog files, your patch should apply. In that case, make sure you’ve run `git-webkit setup` and commit your local changes include the ChangeLog. This will create a commit message derived from your ChangeLogs. Then, remove the ChangeLog edits locally, amend your previous commit with `git commit -a —amend` and re-upload your ChangeLog free patch. - Have pull requests with ChangeLogs Check out your pull request, remove any ChangeLog edits locally and run `git-webkit pr --amend`. Jonathan WebKit Continuous Integration ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Position on font-family: math
Hello WebKittens, I'd like to get opinion about implementing "font-family: math": https://www.w3.org/TR/css-fonts-4/#valdef-font-family-math This is a generic font family name from CSS fonts level 4, which is exactly doing what we need for MathML to get a default user-customizable math font (instead of the hardcoded values we currently have in the mathml.css UA sheet). See also https://webkit-search.igalia.com/webkit/rev/b28eaa8f270a9223d76cc4da9072d42baf2061fc/Source/WebCore/css/mathml.css#78 https://trac.webkit.org/wiki/MathML/Fonts#CustomizingMathFont https://bugs.webkit.org/show_bug.cgi?id=156843 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Position on font-family: emoji (and -webkit-pictograph)
Hi, In 2011, a font-family: -webkit-pictograph was implemented in WebKit [1]. However a new "font-family: emoji" value was added in the CSS Fonts Module Level 4 spec [3]. I understand there is backward compat concerns about removing features but do we agree to add "emoji" as an alias for "-webkit-pictograph", similar to what we did in [3] for "system-ui"? Thanks, [1] https://bugs.webkit.org/show_bug.cgi?id=65197 [2] https://drafts.csswg.org/css-fonts/#font-family-prop [3] https://bugs.webkit.org/show_bug.cgi?id=151493 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On 05/10/2020 16:15, Robert Ma wrote: > On Mon, Oct 5, 2020 at 6:22 AM Frédéric Wang <mailto:fw...@igalia.com>> wrote: > > One thing to take into account is that WebKit's repository is big and > public GitHub/GitLab prevent creating large repository by default. > This > means it might not be possible for contributors to actually fork > WebKit's repository on their account and then create a pull request > (which is the standard way IIUC). Instead, we would probably end up > doing like web-platform-tests and give contributors the permission to > create branches to the WebKit account and make Pull Request to the > master branch. Probably, we should forbid people to commit to the > master > branch directly (I think someone broke WPT's master branch that > way last > year)... > > > Note that this is not exactly the reason we give people write access > in WPT. The WPT repo is not too big to impede forking. Rather, this > was to work around some CI setup constraints (e.g. some secrets not > accessible from forks), most of which have been resolved so the write > access is largely for convenience for active developers (e.g. avoid > having to sync the fork > <https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/syncing-a-fork>). > Right, I didn't mean that but thanks for clarifying Robert (and for adding more info about potential issues with this PR/fork-based workflow). -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On 02/10/2020 18:43, Jonathan Bedard wrote: Hi all, This is great to hear! Several people have already made comments about things that I wanted to say, but I'd just to add my personal point of view... I've used both Mozilla's Phabricator and Chromium's Gerrit for patches/review, and I find both of them great and pretty easy to use. Of course it can take time to get familiar with the UI, but I don't think this is a big blocker, the same is true with any tool... Mozilla and Chromium projects are basically using a separate tracker for bug reports and a Phabricator's differential / Gerrit's CL are connected to a bug entry. Mozilla's differential are attached to Bugzilla as a patch (which is good to make people cc'ed to the bug aware of WIP patch) while Chromium's Gerrit only posts the commit message when the patch lands. Both tools generate a increasing ID in the commit message. However, I think Phabricator's ID is done when the differential is created, not at commit time so this is not what we want for WebKit I guess. In any case, I don't think there should be a problem to add a hook to ensure the ID is created when landing the patch. When you upload a patch you are basically creating a new differential/CL or updating an existing one with a new revision and the difference between revision is calculated automatically. To upload a patch, you execute a script similar to our "webkit-patch upload" which can do extra checks (e.g. style, suggesting reviewers, etc). In any case, Mozilla and Chromium's projects perform these checks when the patch is uploaded too. I'm not sure for Mozilla's phabricator but in Chromium's Gerrit you can also make a CL depend on another one (I mean the review tool and bots will understand that dependency and behave "nicely"), which is helpful to split a change into several patches. I personally prefer both of them over GitHub/GitLab's approach with branches & merge/pull requests. That way you don't have to publish your branches / rebases / forced pushes / squashes, etc Instead, you would do whatever you want in your local clone & branches and always only send the relevant diff as a new revision. Others say similar features are available/planned for GitHub/GitLab, so maybe it's not a problem. One thing to take into account is that WebKit's repository is big and public GitHub/GitLab prevent creating large repository by default. This means it might not be possible for contributors to actually fork WebKit's repository on their account and then create a pull request (which is the standard way IIUC). Instead, we would probably end up doing like web-platform-tests and give contributors the permission to create branches to the WebKit account and make Pull Request to the master branch. Probably, we should forbid people to commit to the master branch directly (I think someone broke WPT's master branch that way last year)... Similarly, public GitHub/GitLab prevent very large files by default. Hopefully, this does not happen in WebKit (we should definitely add a hook to prevent someone to land a big file) but for example that mistake happened in Chromium last year ( https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/tSOmIfXAP2s/m/H07SmWIoCgAJ ) and this broke the sync of their GitHub mirror. I don't know the details of the conversation between Google & GitHub, but it took several weeks and at the end at Igalia we decided to switch our MathML development branch to an internal GitLab repository on which we have full control. Apple might want to weight the pros/cons of managing their own instance VS relying on proprietary / third-party instances for this kind of issue or other customizations. In general, I personally believe it would be good if one only require to use free software tool to contribute to WebKit. But I guess we already made an exception by switching to Slack, so... -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementing MathML stylistic attributes in WebKit
On 02/09/2019 16:11, Frédéric Wang wrote: > Hello, > > Currently MathML attributes mathvariant, displaystyle and scriptlevel > [1] [2] are implemented in WebKit using custom "style resolution" and > "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These > features involve text rendering and interaction with CSS font-size, so > it is difficult to implement them properly and completely that way. > There are known bugs and missing features right now (e.g. mathvariant > transform only applies to one-character strings, automatic > displaystyle/scriptlevel does not work with fractions, etc) Hi, An update on this, we have been discussing these and new properties with the CSSWG: https://github.com/w3c/csswg-drafts/issues/5384 The math-depth / math-style CSS properties are being implemented in Chromium and renamed/exposed/tweaked in Gecko: https://mathml-refresh.github.io/mathml-core/#the-math-style-property https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property So it makes sense to implement them in WebKit (it seems we still don't have a "intent to" mechanism, but people can follow https://bugs.webkit.org/show_bug.cgi?id=195797). The CSSWG is fine with a new text-transform value for automatic italic but using it for other values is controversial (see https://github.com/w3c/csswg-drafts/issues/3775). So if we want to preserve backward compatibility and fix existing bugs with mathvariant, we should probably re-implement it using an internal math-transform property (like what Gecko does) which according to our previous discussion is nowadays possible in WebKit. -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Support "registerProtocolHandler" in WebKit2
Hi, I'm just bumping this old thread, not because I plan to implement it but because I was mentioning it on slack the other day and realized not everybody is #standards: https://webkit.slack.com/archives/CTY7Z24RZ/p1587142539064000 In particular, my question was related to safelist VS blocklist discussion from https://github.com/whatwg/html/issues/3998 From the slack replies as well as https://lists.webkit.org/pipermail/webkit-dev/2019-November/030967.html it seems a complete switch to blocklist is not the option preferred for WebKit (if we ever decide to implement this API) so that's what I commented on the spec / blink-dev discussions. -- Frédéric Wang On 04/07/2015 19:24, Sam Weinig wrote: > (Sorry, had this sitting in my drafts). > > My concern with the registerProtocolHandler() API is that it complicates an > already the very complicated area of custom protocols and a good > implementation requires configuration UI (to choose which of potentially > multiple apps/websites you want a specific protocol to go to) that I am not > sure users are in the position make. > > That, coupled with the small existing usage on the web and very few (if any) > reports from developers that they want this, leads me to think it isn’t a > good API for us to support. > > From an implementation perspective I also have concerns. How is this should > the registration data be managed? Can it fit in the WebSiteData model we are > using for other data? Does it account for non-persistent sessions? And > lastly, can we get the code size of supporting a feature like this to be > smaller? > > - Sam > >> On Jun 7, 2015, at 5:39 PM, Darin Adler wrote: >> >> Are we making progress in this discussion? >> >> Maciej stated that he thinks this is useful for mailto and I think that >> Gyuyoung Kim and Michael Catanzaro stated that they want to do this. >> >> As one next step in the discussion, is there anyone that wants to present a >> use case for a protocol other than mailto? >> >> Sam, Anders, you haven’t replied to the thread since Maciej made his remarks >> two weeks ago. He asked what you dislike about the API. >> >> — Darin >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Switching to XCBuild for Apple builds
On 02/04/2020 04:42, Keith Rollin wrote: > > The patch was just on my local system. I wanted to make sure I’d covered any > issues that were turned up in response to my email before posting. But I’ve > now created the bug noted above and added the patch to it. > Thanks for publishing it. I assume by "Apple builds" (in the title) you mean macOS and iOS ports i.e. it still works for people using the public SDK rather than Apple's internal one. I gave a quick try and I'm not able to build both ports in parallel anymore (will follow-up issues on the bug). I'm generally working with the latest version of Xcode and with the command line, so I guess others are in better position to reply to your concern on legacy support. -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Switching to XCBuild for Apple builds
On 31/03/2020 08:42, Keith Rollin wrote: Hi, > Hi all, > > For several years now, Xcode has included two build systems: the “legacy” > build system and the newer “XCBuild” system (see, for example, > <https://developer.apple.com/videos/play/wwdc2018/408/> and > <https://developer.apple.com/videos/play/wwdc2018/415>, as well as > <https://medium.com/xcblog/xcode-new-build-system-for-speedy-swift-builds-c39ea6596e17> > and > <https://medium.com/xcblog/five-things-you-must-know-about-xcode-10-new-build-system-41676cd5fd6c>). > > WebKit is finally in a position to move to the new build system. However, > this switch is not without consequences. In particular, WebKit has a > complicated build process and requires new XCBuild features only found in > Xcode 11.4. If you build from within the IDE, you will need Xcode 11.4 or > later. Pre-releases have been available for some time on developer.apple.com, > but the final version of Xcode 11.4 was posted to the Mac App Store last week > on March 24, 2020. Out of curiosity, what will be the benefits brought by XCBuild for WebKit developers? (sorry for asking but I don't have time to watch the videos and skimming over the blog post, it seems it's mostly performance improvement for swift compilation?) > When building from the command line, the conditions are less strict. By > default, builds are performed with XCBuild if the `build-webkit` script or > the makefiles detect that Xcode 11.4 or later is installed. If not, builds > are performed with the legacy build system. We can be flexible here because > the build process is controlled by these scripts and makefiles, allowing the > build process to determine the Xcode version before invoking `xcodebuild`. > There is no such opportunity when building within the Xcode IDE, and so the > build requirements are stricter. > > I’ve made the changes to switch over to XCBuild but I haven’t yet posted > them. I want to first find out if this move will cause any issues for > developers who — for whatever reason — need to stay on old versions of Xcode. > If so, please let me know. So I'm not sure I understand but concretely, am I already using the new system if I use the build-script, I've upgraded to XCode 11.4 and rebuilt WebKit from scratch? How can I know which build system I'm using? Or do you mean you have a patch for WebKit that is pending to land? If so, what's the bug number? Thanks, -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Support for scrolling=off and scrolling=noscroll
The spec <https://html.spec.whatwg.org/multipage/rendering.html#the-page> says that iframe and frame elements have a "scrolling" attribute that can be set to "no", "off", or "noscroll" to disable scrollbars. Until now, WebKit has only supported the "no" value but I opened https://bugs.webkit.org/show_bug.cgi?id=208570for the remaining ones. Gecko supports both and intent-to-ship was sent for Chromium too: https://groups.google.com/a/chromium.org/d/msg/blink-dev/qBQCKhzbIRc/RsfZQmf3AQAJ -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal for an "intent to" process for web-exposed features
Hi Ryosuke, just replying quickly to two points: On 27/02/2020 08:08, Ryosuke Niwa wrote: > > Or do you mean that we enabling new feature / behavior by default? If > so, then making such an announcement on webkit-dev requirement for Web > facing feature / behavior change makes sense to me. But we should > never use term such as "shipping". Yes, it's about enabling the feature by default, as I said it's up to the port maintainer to later decide whether they want to disable it. The term "shipping" was copied from Mozilla's template but we can use something else if that's misleading. > > 4. If there's no negative feedback, ship (ports maintainer can > still disable the feature if they want to). > > > We should probably adopt the same 5 business day policy here. Right, the proposal says + 1 week, but that's just an example. -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal for an "intent to" process for web-exposed features
Hi, The idea of an "intent to" process has been raised several times in the past(e.g. in our 2020 goals [1])and some people already use it informally, but it does not seem that we have any agreement right now. Such a process would help to coordinate changes internally (between port maintainers and contributors) and externally (with standard groups, users and other implementers). For the former point, see [2][3][4] for examples of how coordination is not smooth right now.The latter point will give a better understanding of what's happening in WebKit and help web developer advocacy. The Mozilla and Chromium projects have their own process [5] [6]. We can probably start with minimal rules and refine them in the future. We can even make it mandatory only for new web platform features developed under a runtime preference for now (i.e. excluding small features for which it's not worth introducing a flag, behavior changes or deprecation/removal). Below is a proposal based on Mozilla's one. WDYT? Frédéric, on behalf of Igalia's web platform team [1] https://trac.webkit.org/wiki/WebKitGoalsfor2020 [2] Behavior change: https://bugs.webkit.org/show_bug.cgi?id=201641#c49 [3] Deprecation/Removal: https://bugs.webkit.org/show_bug.cgi?id=204125#c7 [4] New feature: https://bugs.webkit.org/show_bug.cgi?id=157743landed in April 2019 and only enabled in https://bugs.webkit.org/show_bug.cgi?id=203644 [5] https://wiki.mozilla.org/ExposureGuidelines [6] https://www.chromium.org/blink/launching-features I/ General process 1. Email webkit-dev with an intent to prototype. 2. Implement the feature normally behind a off-by-default preference. 3. Email webkit-dev with an intent to ship. 4. If there's no negative feedback, ship (ports maintainer can still disable the feature if they want to). II/ Intent to prototype template Subject: Intent to prototype: Summary: Elevator pitch for the new functionality. Bug: Link to https://bugs.webkit.org Standard: Link to standard or public discussions with other browser vendors. Preference: name of flag. Status in other browsers: "shipped", "intent emailed" or "considering". web-platform-tests: Test suite for this feature. III/ Intent to ship template Subject: Intent to ship: As of I intend to turn on by default: https://bugs.webkit.orgto turn the flag on>. This has originally been proposed in https://lists.webkit.org/pipermail/webkit-devintent to prototype>.*If anything changed since that thread please include that information in this email*. It's acceptable to merge the "intent to prototype" into the "intent to ship" email as long as all the relevant requirements are met. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] [Intersection Observer] Accept a Document as an explicit root
Hello, This email is to announce that Igalia has started to implement a recent enhancement to Intersection Observer, that allows users to specify a Document as an explicit root. The typical use case is when such a Document is the one of an iframe. Below is some documentation: WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=208047 W3C issue: https://github.com/w3c/IntersectionObserver/issues/372 Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617154 (intent-to will follow) Chromium bug: https://chromium-review.googlesource.com/c/chromium/src/+/2003750 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Calculate img/video aspect ratio from width and height HTML attributes
On 19/12/2019 14:22, Frédéric Wang wrote: > Hello, > > In [1], we will try and make WebKit rely on the width and height HTML > attributes of the and elements in order to determine their > aspect ratio, so that it can be used for sizing the image using CSS, > before the content loads. > > HTML and CSS standardization groups already reached consensus on this > proposal [2] and there are WPT tests for it. Moreover this is already > shipped in Gecko [3] and Chromium [4]. > > [1] https://bugs.webkit.org/show_bug.cgi?id=201641 > [2] https://github.com/WICG/intrinsicsize-attribute/issues/16 > [3] > https://groups.google.com/forum/#!msg/mozilla.dev.platform/H9j3aJ20IgE/fs9Df3loCQAJ > [4] > https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Compute$20img$2Fvideo$20aspect$20ratio$20from$20width$20and$20height$20HTML$20attributes%7Csort:date/blink-dev/GePU9T8UpEc/uQWhDZeODwAJ > Hi, Just for completeness, we intend to enable the flag by default in https://bugs.webkit.org/show_bug.cgi?id=207880 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API
On 10/12/2019 17:52, Frédéric Wang wrote: > Hi everybody, > > Cathie has taken over my work on this. In order to facilitate review, > we decided to split the patch into three parts. If there is no > opposition, we'll probably go ahead and land (1) and (2) below. But in > any case, we need approval from Apple reviewers on (3). > > (1) Introduce CSS/IDL changes under a new preference flag > https://bugs.webkit.org/show_bug.cgi?id=205009 > > I already r+ed this part and I think Simon Fraser had reviewed > this part > before so I don't expect it to be controversial. The only question is > whether it makes sense to land this before the rest of the > implementation > is done. I guess it is ok to take it with (2) in any case. > > (2) Implement a generic animator class running in the scrolling > thread, based > on the one that already exists on GTK for smooth scrolling. > https://bugs.webkit.org/show_bug.cgi?id=204882 > > Simon has also partially reviewed this piece and modulo minor > changes I > think it looks good to me too. The issue here is that I'm not sure > I should > review it given I wrote most of this code. Also, it's probably not > the most > efficient approach and ports should probably rely on any existing > platform API to animate scrolling when available. However, it is a > necessary > fallback and the preference flag is turned off for now, so I think > it is > safe to take this for now... > > (3) Implement scroll animator in the UI process for iOS, based on native > platform support (UIScrollView). > https://bugs.webkit.org/show_bug.cgi?id=204936 > > This part hasn't been reviewed yet although the general design has > been > discussed with Simon. Alternatively, this patch can be taken > before (2) > since the two are more or less independent and each one really > only depends > on (1). > > I'm interested to hear about suggestions to rely on native scroll > animations for other ports. However, this can probably be done in > follow-up patches. Web developers really requested support on iOS and > it seems very important to have (3) for that port. > > Thank you, Hi, As announced, parts (1) and (2) have landed and there does not seem to have been any issue in the past week. We'll go ahead with part (3). -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Calculate img/video aspect ratio from width and height HTML attributes
Hello, In [1], we will try and make WebKit rely on the width and height HTML attributes of the and elements in order to determine their aspect ratio, so that it can be used for sizing the image using CSS, before the content loads. HTML and CSS standardization groups already reached consensus on this proposal [2] and there are WPT tests for it. Moreover this is already shipped in Gecko [3] and Chromium [4]. [1] https://bugs.webkit.org/show_bug.cgi?id=201641 [2] https://github.com/WICG/intrinsicsize-attribute/issues/16 [3] https://groups.google.com/forum/#!msg/mozilla.dev.platform/H9j3aJ20IgE/fs9Df3loCQAJ [4] https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Compute$20img$2Fvideo$20aspect$20ratio$20from$20width$20and$20height$20HTML$20attributes%7Csort:date/blink-dev/GePU9T8UpEc/uQWhDZeODwAJ -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feedback on Blink's text fragment directive proposal
On 02/12/2019 21:22, David Bokan wrote: > Hello webkit-dev, > > I'd like to solicit feedback as well as an official position from > Webkit on our proposal for the text fragment > directive: https://github.com/WICG/ScrollToTextFragment. > > In summary: this is a feature that allows authors and users to craft > URLs to pages and specify a snippet of text on the page as a > subresource (visually highlighting it and scrolling it into view). > Analogous to element-id based fragment anchors but for text. > > You can try this out today in Chrome Beta by > enabling chrome://flags/#enable-text-fragment-anchor. Here's an > example link: > > https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view > > Relevant Links: > > <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md> > Explainer > <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md> > Spec <https://wicg.github.io/ScrollToTextFragment/> > TAG Review <https://github.com/w3ctag/design-reviews/issues/392> > (Currently Suspended) Blink Intent Thread > <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ> > Issue on Mozilla standards-positions > <https://github.com/mozilla/standards-positions/issues/194> > > We've been using the GitHub repo for issue tracking but happy to take > feedback (official or otherwise) in any form. > > Thank you! > David > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev Hi, I think some of the webkit-dev members have already replied on the Blink thread. Just to repeat here, I think the concerns Igalia had regarding the lack of details to implement the algorithm have been addressed in the latest versions of the spec. We haven't checked again if the WPT coverage is good enough now though. -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API
Hi everybody, Cathie has taken over my work on this. In order to facilitate review, we decided to split the patch into three parts. If there is no opposition, we'll probably go ahead and land (1) and (2) below. But in any case, we need approval from Apple reviewers on (3). (1) Introduce CSS/IDL changes under a new preference flag https://bugs.webkit.org/show_bug.cgi?id=205009 I already r+ed this part and I think Simon Fraser had reviewed this part before so I don't expect it to be controversial. The only question is whether it makes sense to land this before the rest of the implementation is done. I guess it is ok to take it with (2) in any case. (2) Implement a generic animator class running in the scrolling thread, based on the one that already exists on GTK for smooth scrolling. https://bugs.webkit.org/show_bug.cgi?id=204882 Simon has also partially reviewed this piece and modulo minor changes I think it looks good to me too. The issue here is that I'm not sure I should review it given I wrote most of this code. Also, it's probably not the most efficient approach and ports should probably rely on any existing platform API to animate scrolling when available. However, it is a necessary fallback and the preference flag is turned off for now, so I think it is safe to take this for now... (3) Implement scroll animator in the UI process for iOS, based on native platform support (UIScrollView). https://bugs.webkit.org/show_bug.cgi?id=204936 This part hasn't been reviewed yet although the general design has been discussed with Simon. Alternatively, this patch can be taken before (2) since the two are more or less independent and each one really only depends on (1). I'm interested to hear about suggestions to rely on native scroll animations for other ports. However, this can probably be done in follow-up patches. Web developers really requested support on iOS and it seems very important to have (3) for that port. Thank you, On 14/11/2018 19:58, Frédéric Wang wrote: > Hi all, > > The main implementation is now submitted for review at: > https://bugs.webkit.org/show_bug.cgi?id=188043 > > It has some issue with smooth scrolling via scrollIntoView on nested > scrollers but I don't plan to work on this until the main part is > merged. See https://bugs.webkit.org/show_bug.cgi?id=189907 > > On 20/09/2018 22:26, Frédéric Wang wrote: >> Hi all, >> >> This email is to announce that I have started to work on (programmatic) >> smooth scrolling in WebKit from the CSSOM View specification [1]. To use >> this effect, web developers can pass a behavior parameter (auto, smooth, >> or instant) to Element.scroll, Element.scrollTo, Element.scrollBy, >> Element.scrollIntoView, Window.scroll, Window.scrollTo or >> Window.scrollBy [2]. When behavior is auto, the instant/smooth >> characteristic is actually taken from the value of a new CSS >> scroll-behavior property [3]. This new feature will be protected by a >> compile flag (enabled by default) and a runtime flag (an experimental >> feature). If you are interested, you can follow advancement on Bugzilla [4]. >> >> Incidentally (and since that was convenient to do it before) I also >> added some basic support for new ScrollIntoView options [5] [6] that >> allow to specify how you want the revealed element to be aligned with >> respect to its scrollable ancestors. >> >> Cheers, >> >> >> Frédéric >> >> [1] https://drafts.csswg.org/cssom-view >> [2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions >> [3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior >> [4] https://bugs.webkit.org/show_bug.cgi?id=188043 >> [5] https://bugs.webkit.org/show_bug.cgi?id=189258 >> [6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Supporting for finding ref tests
On 12/11/2019 20:06, Simon Fraser wrote: >> On Nov 12, 2019, at 4:52 AM, Frédéric Wang wrote: >> >> On 09/11/2019 04:02, Ryosuke Niwa wrote: >>>>>> - Requires us modifying each port's DRT to support this format >>>>>> >>>>>> No, it just requires webkitpy hacking which I've done in the patch. >>>>> I'm not certain writing a bunch of regular expressions in webkitpy is >>>>> a reliable mechanism to find expected results. Another issue I found >>>>> back then was that it significantly slowed run-webkit-tests' startup >>>>> time because WPT has a workflow to find all tests & their expected >>>>> results upfront before any tests could run. >>>> The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, >>>> and our importer use to find the ref tests. >>>> >>>> We don't find references up-front; only when running each test. This patch >>>> does add some overhead for parsing each test file, >>>> which I measured to be about 1-2 sec on a directory which took 30s to run. >>>> I think this slight slowdown is worthwhile (we could >>>> probably eliminate it with some webkitpy optimizations). >>> Hm... that's ~3% overhead. >> @Simon: I agree with Ryosuke that 3% sounds big. IIUC you are parsing >> the HTML file when running each test? I thought that there is a >> MANIFEST.json file which is supposed to cache that information, why >> can't we use it? > I don't see any files call MANIFEST.json in the wpt repo. This is a generated file: https://github.com/web-platform-tests/wpt/blob/7c50c216081d6ea3c9afe553ee7b64534020a1b2/tools/runner/update_manifest.py#L12 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Supporting for finding ref tests
On 09/11/2019 04:02, Ryosuke Niwa wrote: > >>>> - Requires us modifying each port's DRT to support this format >>>> >>>> No, it just requires webkitpy hacking which I've done in the patch. >>> I'm not certain writing a bunch of regular expressions in webkitpy is >>> a reliable mechanism to find expected results. Another issue I found >>> back then was that it significantly slowed run-webkit-tests' startup >>> time because WPT has a workflow to find all tests & their expected >>> results upfront before any tests could run. >> The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, and >> our importer use to find the ref tests. >> >> We don't find references up-front; only when running each test. This patch >> does add some overhead for parsing each test file, >> which I measured to be about 1-2 sec on a directory which took 30s to run. I >> think this slight slowdown is worthwhile (we could >> probably eliminate it with some webkitpy optimizations). > Hm... that's ~3% overhead. @Simon: I agree with Ryosuke that 3% sounds big. IIUC you are parsing the HTML file when running each test? I thought that there is a MANIFEST.json file which is supposed to cache that information, why can't we use it? -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementing MathML stylistic attributes in WebKit
On 02/09/2019 22:12, Ryosuke Niwa wrote: > > On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang <mailto:fw...@igalia.com>> wrote: > > > Currently MathML attributes mathvariant, displaystyle and > scriptlevel [1] [2] are implemented in WebKit using custom "style > resolution" and "one-glyph rendering" inside the MathML layout > code [3] [4] [5]. These features involve text rendering and > interaction with CSS font-size, so it is difficult to implement > them properly and completely that way. There are known bugs and > missing features right now (e.g. mathvariant transform only > applies to one-character strings, automatic > displaystyle/scriptlevel does not work with fractions, etc) > > Several years ago, Gecko used to do something similar but that was > causing a lot of problems (dynamic update, assertion failures...). > At the end, this is now implemented in Gecko more reliably by > mapping the attributes to internal CSS properties ; [6] is based > on that. When I tried to do something like this in WebKit three > years ago, I was only able to rely on proprietary -webkit-* > extensions exposed to users [7]. > > So my questions are: > > (1) What is WebKit's mechanism to implement such stylistic attributes? > > > It looks like -internal-text-autosizing-status is such a property. > This is a property the author can never set and we set it internally > for implementation purposes. > ComputedStyleExtractor::valueForPropertyInStyle manually skips it so > it's never exposed anywhere. > > One subtle thing I didn't check is whether it would affect the CSS > parser or not (as in whether it would be considered as a valid CSS > property or not). There might be some subtle effect there. > > -webkit-text-decorations-in-effect is also a CSS property we use > internally to compute the effective set of text decorations applied to > text for editing purposes. The author can never set it but it's > unfortunately exposed via computed style. > > (2) Is it possible to implement internal (i.e. not web-exposed to > users) CSS properties/values in WebKit? > > > It appears possible today using the technique deployed by > CSSPropertyInternalTextAutosizingStatus. > > Thanks for the pointers! I think it is worth trying to (re-)implement these MathML attributes using internal properties. -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Implementing MathML stylistic attributes in WebKit
Hello, Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc) Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7]. So my questions are: (1) What is WebKit's mechanism to implement such stylistic attributes? (2) Is it possible to implement internal (i.e. not web-exposed to users) CSS properties/values in WebKit? (3) Is it ok to add more -webkit-* properties/values or should these properties be standardized at the CSS WG instead? I understand answers to these general questions from other browser project is either use internal properties or standardize them. Thanks, Frédéric PS: For a concrete example, see [8]. Automatic mathvariant is used for italic variables while font-size in fractions is calculated according to displaystyle / scriptlevel rules. The latter is incorrect (check the attached screenshot) while selection highlight is broken for the former. [1] https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute [2] https://mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptlevel-attributes [3] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css [4] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/MathMLStyle.cpp [5] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/RenderMathMLToken.cpp#L593 [6] https://mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout [7] https://bugs.webkit.org/show_bug.cgi?id=133845#c5 [8] https://bug-201242-attachments.webkit.org/attachment.cgi?id=377730 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove SVGTests.hasExtension?
On 10/06/2019 17:31, Maciej Stachowiak wrote: > > Since SVG WG resolved to remove it, has it in fact been removed from > the SVG spec? Right, compare SVG 2 (W3C Recommendation 04 October 2018): https://www.w3.org/TR/SVG2/types.html#InterfaceSVGTests and SVG 1.1 (W3C Recommendation 16 August 2011): https://www.w3.org/TR/SVG11/types.html#InterfaceSVGTests/ / -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove SVGTests.hasExtension?
Patch for Firefox was uploaded 4 years ago and they announced plan for removal at that time. We pinged Mozilla some weeks ago about it, they landed the patch and announced it: https://bugzilla.mozilla.org/show_bug.cgi?id=1133175 https://www.fxsitecompat.com/en-CA/docs/2019/hasextension-has-been-removed-from-some-svg-interfaces/ https://www.fxsitecompat.com/en-CA/docs/2015/several-properties-will-be-removed-from-svgsvgelement/ I didn't check Edge, but Microsoft is migrating to Chromium so that's not going to be there in future versions. On 07/06/2019 20:40, Ryosuke Niwa wrote: > Does Edge support it? When did Firefox remove this feature? > > On Fri, Jun 7, 2019 at 1:55 AM Frédéric Wang <mailto:fw...@igalia.com>> wrote: > > Hi, > > 4 years ago, the SVG WG resolved to remove SVGTests.hasExtension due to > lack of use and being a poor API. > It was removed from Chromium at that time and has been removed from > Firefox recently. > > I'm not sure whether the WebKit community is willing to keep that > feature. Anyway I opened a bug entry to track possible removal: > > https://bugs.webkit.org/show_bug.cgi?id=198652 > > -- > Frédéric Wang > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- > - R. Niwa -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Remove SVGTests.hasExtension?
Hi, 4 years ago, the SVG WG resolved to remove SVGTests.hasExtension due to lack of use and being a poor API. It was removed from Chromium at that time and has been removed from Firefox recently. I'm not sure whether the WebKit community is willing to keep that feature. Anyway I opened a bug entry to track possible removal: https://bugs.webkit.org/show_bug.cgi?id=198652 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cannot load pages with run-safari --ios-simulator (public SDK)
On 06/06/2019 19:00, Frédéric Wang wrote: > On 06/06/2019 18:32, Dan Bernstein wrote: >> When dyld aborts this way it logs the reason (based on the backtrace, >> likely a missing symbol). You may be able to find the message from >> dyld in the macOS Console app (the Simulator app also allows you to >> open the Simulator system log, if I remember correctly). > Thanks. Unfortunately, the macOS console does not contain much info. > > Here are possibly relevant errors in the simulator system log: > > Unknown key for Boolean: EnablePressuredExit > Unknown key for Boolean: EnableTransactions > Unknown key for integer: _DirtyJetsamMemoryLimit > unsupported XPC object: OS_xpc_dictionary > > These are logged at initial launch though. I can't see anything > particular when the page keeps crashing again and again. > I moved this discussion to https://bugs.webkit.org/show_bug.cgi?id=198646 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cannot load pages with run-safari --ios-simulator (public SDK)
On 06/06/2019 18:32, Dan Bernstein wrote: > > When dyld aborts this way it logs the reason (based on the backtrace, > likely a missing symbol). You may be able to find the message from > dyld in the macOS Console app (the Simulator app also allows you to > open the Simulator system log, if I remember correctly). Thanks. Unfortunately, the macOS console does not contain much info. Here are possibly relevant errors in the simulator system log: Unknown key for Boolean: EnablePressuredExit Unknown key for Boolean: EnableTransactions Unknown key for integer: _DirtyJetsamMemoryLimit unsupported XPC object: OS_xpc_dictionary These are logged at initial launch though. I can't see anything particular when the page keeps crashing again and again. -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Cannot load pages with run-safari --ios-simulator (public SDK)
_header const*, int, char const**, long, macho_header const*, unsigned long*) + 1167 frame #29: 0x0001053cc036 dyld`_dyld_start + 54 -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML Refresh Heads up
On 20/03/2019 20:45, Ryosuke Niwa wrote: > > I agree on the goal but disagree on the suggestion. At minimum, we > should decide each case separately and try to collect some data before. > > We can continue to agree to disagree on this point. But I strongly > object to removing any features from MathML implementation of > WebKit without having done comprehensive compatibility testing > with various iOS and macOS apps that use MathML. > I'm also happy with more testing with iOS / macOS apps. I was just concerned by the "for now" and the "there isn't any easy way to do it" in your initial emails, it seems you were not open to accept any change for an undetermined period of time, just because of your ports... > I guess one way to satisfy your desire without breaking WebKit > in iOS and macOS would be to add a runtime feature flag which > disables the parts of MathML that's not a part of core MathML, > and then only enable this feature in your own port. That would > allow you to have the same set of features between your > products without breaking our ports. > > ...however that proposal from you last email sounds more constructive. That would still be extra burden for us to manage deprecated MathML code and the corresponding tests, but at least that will give us the opportunity to start disabling features & run tests without them, to better see which parts we can ignore when comparing code between web engines and even to have beta testers providing feedback. So that seems a good trade off until Apple is ready to accept the changes (or not). > I really don't care what maintainers of Blink say or do about > MathML because they don't have MathML implementation right > now. My primary concern as I've stated multiple times is iOS > and macOS apps that currently use MathML. > Again, you are the one who brought up that topic in this thread. If you really don't care about Blink maintainers or Google's opinion then please just don't mention them. >> These all seem like something out in the wild might be >> using. https://github.com/search?q=mathml+fontweight=Code yields >> quite a few examples in which fontweight content attribute is >> being used for example. > > MathML is used as an exchange format in various tools, > standards and documents so that's not really surprising to get > matches. However, the MathML Core spec targets usage in web > engines so what we need instead is to check content that is > actually served to web engines in general and to WebKit in > particular. > > Note: There are straighforward CSS polyfills for the > attributes previously mentioned. A JS polyfill would be needed > for MathML nonzero unitless lengths (if they are really used) > but removing the possibility to write "5" instead of "500%" is > part of the general goal to align more with HTML/CSS. > Regarding fontweight, it is known to require some extra > code/tests in Gecko/Stylo in order to handle conflicts with > mathvariant ( WebKit doesn't handle such conflicts > > https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122 > ). > > An existence of a bug in our code is not an evidence that the > entire feature can be removed. > That was not my point. I was just trying to explain that there are more issues involved when you analyze carefully each case, you cannot just rely on generic claims, quick searches or unilateral approaches in order to make a decision. Anyway that was just a side note, it's probably not worth entering into details on this mailing list. Thank you, -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML Refresh Heads up
On 16/03/2019 00:04, Ryosuke Niwa wrote: > On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <mailto:fw...@igalia.com>> wrote: > > Hi Ryosuke and Myles, > > Thank you for your reply. First, the exact thing about what will > be in MathML Core is still open, people are welcome to join and > participate to the MathML CG [1] or comment on the GitHub tracker [2]. > > Our plan was also to remove features from WebKit but of course > ultimately the consensus has to be made in the WebKit community > (hence our heads up email). What do you suggest? Should we send > "intent to remove" to this mailing list? > > > Ultimately, we need some testing to ensure whatever iOS and macOS > apps, or websites that specifically target WebKit and Gecko that use > MathML don't get broken by those removals. Because there isn't an easy > way to do that right now, my suggestion is not remove any features for > now. > I agree on the goal but disagree on the suggestion. At minimum, we should decide each case separately and try to collect some data before. > Put it another way, what's the benefit of removing features in WebKit > before fixing other MathML bugs? This question sounds rhetorical, but basically this is already said in the initial email: improve browser interoperability and reduce complexity of current implementations. Especially, at Igalia we are working on several engines in parallel and it's much easier if the implementation logic and set of WPT tests is consistent in order to compare the code, fix bugs and implement new features. Maintaining WebKits-specific features and tests would be an extra burden, so it would be preferable to avoid it when possible. > If the only benefit is that Blink may have an easier time implementing > the rest and therefore might be more interoperable, I really don't buy > that argument given MathML isn't supported at all in Blink today. Note that you are the only one who suggested on this thread that our WebKit announcement is made according to Google's opinion or Blink's development plan... I get that having more features in Gecko/WebKit might be an interoperability concern and maybe Apple actually has more information from Google, but so far Google people actually seem more interested in the two other points of the initial email. FWIW, the removal/deprecation discussions are currently led by the MathML Refresh CG (which include browser implementers from Mozilla/Igalia, people from the former Math WG, scholars, publishers, a11y experts, authors of MathML tools...) and rely heavily on the experience from WebKit/Gecko/Stylo implementations. > These all seem like something out in the wild might be > using. https://github.com/search?q=mathml+fontweight=Code yields > quite a few examples in which fontweight content attribute is being > used for example. MathML is used as an exchange format in various tools, standards and documents so that's not really surprising to get matches. However, the MathML Core spec targets usage in web engines so what we need instead is to check content that is actually served to web engines in general and to WebKit in particular. Note: There are straighforward CSS polyfills for the attributes previously mentioned. A JS polyfill would be needed for MathML nonzero unitless lengths (if they are really used) but removing the possibility to write "5" instead of "500%" is part of the general goal to align more with HTML/CSS. Regarding fontweight, it is known to require some extra code/tests in Gecko/Stylo in order to handle conflicts with mathvariant ( WebKit doesn't handle such conflicts https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122 ). -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML Refresh Heads up
On 16/03/2019 00:29, Maciej Stachowiak wrote: > It’s easier for us to check Apple Books and iOS App compatibility for > a batch of possible removals at once, instead of one at a time. We can > start by looking at the set of items below. > > It’s helpful to give a heads-up other than the normal review process, > because our main concern is compatibility, and not all reviewers will > be able to easily access the corpus of app-specific or books-specific > content that may be affected. > > We assume web compatibility is not a major issue since MathML isn’t in > all browsers and in general is not widely used on websites, but there > might also be some value in doing web usage analysis for these > features if there’s any meaningful web usage of MathML at all. We'll try to provide heads-up on this mailing list and will work with the MathML Refresh CG in order to get more statistics. Having data from Apple products would be very useful, here are some first questions (this includes elements/attributes/values raised by the CG for removal/deprecation but most have not been decided yet): * Usage statistics for MathML elements used. More specifically, which of the following elements are used: munder, mover, msub, msup, msubsup, mlabeledtr, merror, mphantom, maction, mglyph, mfenced, mstyle, ms * Usage statistics for MathML attributes. More specifically, which of the following attributes are used: mathvariant, numalign, denomalign, align (on munderover/munder/mover elements), bevelled, subscripshift, superscriptshift, other, macros, mode, fontfamily, index, fontfamily, fontweight, fontstyle, fontsize, color, background, veryverythinmathspace, verythinmathspace, thinmathspace, mediummathspace, thickmathspace, verythickmathspace, veryverythickmathspace * Usage statistics for MathML attributes on the mstyle and math elements. More specifically, do mstyle elements use any attribute other than displaystyle, dir, mathsize, mathbackground, mathcolor, mathvariant, scriptlevel? * Attribute values. Is any of the following attribute used? - linethickness attribute with value "thin", "thick" or "medium" - mathsize attribute with value "small", "normal" or "big" - attribute with value a nonzero number without unit (e.g. "4") other than scriptlevel - attribute with value "veryverythinmathspace", "verythinmathspace", "thinmathspace", "mediummathspace", "thickmathspace", "verythickmathspace" or "veryverythickmathspace". - notation attribute containing the value "radical" (e.g. notation="radical circle") - attribute with leading or trailing white space characters (U+0020, U+0009, U+000A, U+000D or U+000C). For example width=" 5em ". * Trailing/leading whitespace in token elements (mi, mtext, mn, mo, mtext, ms). Do token elements contain text content with leading or trailing white space characters (U+0020, U+0009, U+000A, U+000D or U+000C). For example x . Thanks, -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML Refresh Heads up
Hi Ryosuke and Myles, Thank you for your reply. First, the exact thing about what will be in MathML Core is still open, people are welcome to join and participate to the MathML CG [1] or comment on the GitHub tracker [2]. Our plan was also to remove features from WebKit but of course ultimately the consensus has to be made in the WebKit community (hence our heads up email). What do you suggest? Should we send "intent to remove" to this mailing list? Or is it enough to cc' Apple reviewers on bugs in order to get the approval? Something else? For now, these are the features the CG has already agreed to not include in MathML Core (more to come). We would like to propose to remove them from WebKit: * "thin", "thick", "medium" values of mfrac's linethickness attribute ( https://github.com/mathml-refresh/mathml/issues/4) * "small" "normal" "big" values of mathsize attribute ( https://github.com/mathml-refresh/mathml/issues/7) * nonzero unitless values for MathML lengths ( https://github.com/mathml-refresh/mathml/issues/24) * fontfamily, fontweight, fontstyle, fontsize, color, background MathML attributes ( https://github.com/mathml-refresh/mathml/issues/5) In any case, it would be very appreciated to get some analysis about the usage of MathML markup used in Apple's product. How can we proceed to obtain it? Thanks, [1] https://www.w3.org/community/mathml4/ [2] https://github.com/mathml-refresh/mathml/issues/ On 15/03/2019 22:33, Myles C. Maxfield wrote: > > >> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote: >> >> >> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang > <mailto:fw...@igalia.com>> wrote: >> >> Hello WebKit developers, >> >> As some of you may know, Igalia is working on MathML support in >> Chromium >> this year [1]. As part of that effort we joined a new MathML Refresh >> Community Group [2] and one goal is to focus on a core spec for >> browser >> implementations [3] to: >> - Remove deprecated/uncommon/duplicate math features that could be >> implemented by polyfills (relying on MathML core and other web >> technologies). >> >> >> I'd be very much concerned about backwards compatibility here when it >> come to removing any features. >> It's important to notice that WebKit is also used by hundreds of >> thousands of iOS apps and macOS apps. >> How do we know we won't break those applications? >> >> In general, I don't agree with whatever Google said about MathML >> being too complex, etc… > > The original sentence doesn’t say they will be removing anything in > WebKit. There are plenty of features that have been removed from specs > that we continue supporting in WebKit for backwards compatibility. > > We could also consider migrating our implementation to a JS polyfill > if one exists. > > Is there a characterization of which features are planned for > deprecation? We might be able to do some analysis on iBooks' and iOS > apps’ content. > >> >> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to >> help implementation and conformance testing. >> - Align MathML with CSS/HTML (parsing, layout...), introducing >> new web >> platform features (CSS, fonts...) for math if necessary. >> > > This sounds wonderful! A more coherent MathML story going forward > would be fantastic. > >> >> On the other hand, these seem like very valuable improvements. >> >> We expect that this effort will improve browser interoperability and >> reduce complexity of current implementations. >> >> >> Given there aren't too many websites that deploy MathML directly on >> production, my concerns are more about existing iOS and madOS apps >> that embed WKWebView or WebView / UIWebView and use MathML. >> >> - R. Niwa >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev > -- Frédéric Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] MathML Refresh Heads up
Hello WebKit developers, As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to: - Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies). - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to help implementation and conformance testing. - Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary. We expect that this effort will improve browser interoperability and reduce complexity of current implementations. This is just a heads up to say that we will send patches to update/remove/add features. For people who are interested, we opened a meta bug to track these changes [4]. Frédéric Wang and Rob Buis, [1] https://mathml.igalia.com/ [2] https://mathml-refresh.github.io/ [3] https://mathml-refresh.github.io/mathml-core/ [4] https://bugs.webkit.org/show_bug.cgi?id=195797 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Turning on/off web preferences during iOS development
Hi everybody, I was wondering if there is an easy way to enable or disable a web preference on iOS (simulator). Some of them are in the "experimental features" menu but (at least with the public SDK) it has not always worked well during development [1]. Moreover, most of the preferences are now "internal features". For the mac port, one can use the Experimental/Internal features menu in minibrowser. For other ports, one can just modify the default value in WebPreferences.yaml and rebuild, but that's a bit against the idea of a runtime setting. Any idea? Thanks, Frédéric [1] https://bugs.webkit.org/show_bug.cgi?id=182485 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API
Hi all, The main implementation is now submitted for review at: https://bugs.webkit.org/show_bug.cgi?id=188043 It has some issue with smooth scrolling via scrollIntoView on nested scrollers but I don't plan to work on this until the main part is merged. See https://bugs.webkit.org/show_bug.cgi?id=189907 On 20/09/2018 22:26, Frédéric Wang wrote: > Hi all, > > This email is to announce that I have started to work on (programmatic) > smooth scrolling in WebKit from the CSSOM View specification [1]. To use > this effect, web developers can pass a behavior parameter (auto, smooth, > or instant) to Element.scroll, Element.scrollTo, Element.scrollBy, > Element.scrollIntoView, Window.scroll, Window.scrollTo or > Window.scrollBy [2]. When behavior is auto, the instant/smooth > characteristic is actually taken from the value of a new CSS > scroll-behavior property [3]. This new feature will be protected by a > compile flag (enabled by default) and a runtime flag (an experimental > feature). If you are interested, you can follow advancement on Bugzilla [4]. > > Incidentally (and since that was convenient to do it before) I also > added some basic support for new ScrollIntoView options [5] [6] that > allow to specify how you want the revealed element to be aligned with > respect to its scrollable ancestors. > > Cheers, > > > Frédéric > > [1] https://drafts.csswg.org/cssom-view > [2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions > [3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior > [4] https://bugs.webkit.org/show_bug.cgi?id=188043 > [5] https://bugs.webkit.org/show_bug.cgi?id=189258 > [6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental and (new) Internal feature flags
On 05/11/2018 09:28, Manuel Rego Casasnovas wrote: > I'm not sure about DRT. It seems you need to modify > https://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/TestOptions.cpp#L102 > in order that these headers work there. Thanks rego. Probably this file should assert or log error for unknown options, so that people realize they need to implement the parsing. I opened https://bugs.webkit.org/show_bug.cgi?id=191303 -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing iOS/WK1?
On 23/10/2018 17:44, Ali Juma wrote: > Try passing the argument "-1": > > run-webkit-tests --ios-simulator -1 Great thanks for the hint, I think this --dump-render-tree could be useful indeed to check WK1. However, in the particular scrolling tests I'm considering, I'm relying a lot on testRunner.runUIScript to execute basic gestures or emulate the find UI and most of these APIs are not implemented (easily implementable?) in Tools/DumpRenderTree/ios/UIScriptControllerIOS.mm -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Testing iOS/WK1?
Hi all, During the WebKit Contributors Meeting, Simon Fraser suggested that I should verify some of the my patches using WK1. Hence I did some experiments (again): * When I run run-webkit-tests, whatever the value specified via --platform, the selected expectation is always a "wk2" file and the code executed is from WebKit (i.e. WK2 == non-legacy). * I wrote a dummy iOS app using the deprecated UIWebView [1] and tried to launch it with Tools/Scripts/run-webkit-app --ios-simulator /path/to/WebKitLegacyApp.app ; that seems to be working (code from WebKitLegacy is indeed executed). Also, page is loaded and properly rendered at startup so I can somewhat test it. However, the app does not reply to user interaction so it's difficult to do manual testing (not to mention features like the Find UI are not available). Also, I have not checked but IIRC the EWS bots actually only run iOS/WK2 tests, right? Any idea/suggestion regarding how one could test iOS/WK1? PS: I'm using the public Xcode SDK. In particular I only have access to the simulator. [1] https://github.com/fred-wang/WebKitLegacyApp -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc
On 10/09/2018 10:41, Frédéric Wang wrote: > The new behavior is enabled for tests after > https://trac.webkit.org/changeset/235806/webkit > Essentially, this means that if you want set/get the scroll position of > the test pages, you should now just use document.scrollingElement > instead of document.body. > > I'll wait a few days before proposing to set it to > DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and allow wider testing : > https://bugs.webkit.org/show_bug.cgi?id=189472 Given the new policy for experimental features and given that the behavior has already been enabled for all tests for 2 weeks now, we should either 1) remove the flag from the experimental category and enable by default or 2) disable it for tests and enable it on a per-test basis using headers. I'm proposing the former in https://bugs.webkit.org/show_bug.cgi?id=189472 Note that enabling the flag is a big behavior change that might impact users but at the same time will fix an old compatibility issue between WebKit (non-standard behavior) VS Chromium/Gecko/Edge (CSSOMView behavior). -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental and (new) Internal feature flags
On 12/09/2018 23:48, Dean Jackson wrote: > What about testing? > > > You can turn both experimental and internal features on via headers in > WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For > example... > > IIUC some platforms (WK1?) still use DumpRenderTree to run tests? Are such headers taken into account on these platforms too? -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API
Hi all, This email is to announce that I have started to work on (programmatic) smooth scrolling in WebKit from the CSSOM View specification [1]. To use this effect, web developers can pass a behavior parameter (auto, smooth, or instant) to Element.scroll, Element.scrollTo, Element.scrollBy, Element.scrollIntoView, Window.scroll, Window.scrollTo or Window.scrollBy [2]. When behavior is auto, the instant/smooth characteristic is actually taken from the value of a new CSS scroll-behavior property [3]. This new feature will be protected by a compile flag (enabled by default) and a runtime flag (an experimental feature). If you are interested, you can follow advancement on Bugzilla [4]. Incidentally (and since that was convenient to do it before) I also added some basic support for new ScrollIntoView options [5] [6] that allow to specify how you want the revealed element to be aligned with respect to its scrollable ancestors. Cheers, Frédéric [1] https://drafts.csswg.org/cssom-view [2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions [3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior [4] https://bugs.webkit.org/show_bug.cgi?id=188043 [5] https://bugs.webkit.org/show_bug.cgi?id=189258 [6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unified sources have broken our #include hygiene
Hi, I've recently found two non-trivial issues with unified builds. They are not missing #include but instead conflicts between C++ files: - Two C++ files including the same header but with a #define directive set to different values [1]. - One C++ file including a header with implicit template instantiation in an inline function before an explicit template specialization in a second C++ file. [2] I guess there could be more examples like this (e.g. functions with conflicting names in two C++ files...). Should we allow to prevent some files to be included in unified build? This is possible in Mozilla's build system for example [3]. Or should we always try to re-write the code to fix the conflicts between files? This might go against our usual practice: For example the current solution I have for [2] is to move the function from the header to its implementation C++ file, losing potential performance benefit of inlining... [1] https://bugs.webkit.org/show_bug.cgi?id=189579 [2] https://bugs.webkit.org/show_bug.cgi?id=189541 [3] https://dxr.mozilla.org/mozilla-central/source/dom/canvas/moz.build#70 On 02/09/2018 02:14, Simon Fraser wrote: > Unified sources allow you to get away without #including all the files you > need in a .cpp file, because some earlier file in the group has probably > already included them for you. > > This means that when you add a new file to the build, and the unified sources > get shuffled around, you end up with a long list of build breakages, some > platform-specific, that you can only fix by repeating EWS trials. Here's an > example: https://bugs.webkit.org/show_bug.cgi?id=189223. That patch added on > new file in Source/WebCore/rendering, which required unrelated #include > changes in at least: > > rendering/RenderBlockFlow.cpp: > rendering/RenderFrame.cpp: > rendering/RenderImage.cpp: > > How can we solve this? Should we have an EWS that builds non-unified? Can we > somehow have the style checker do #include enforcement? > > Simon > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental and (new) Internal feature flags
Thanks for the heads-up. Some random thoughts on this: * For WPT tests, I would like a solution that does not discourage WebKit developers to contribute new tests to upstream WPT. It seems to me that such a risk exists for the proposal based on a header in the files. * The per-directory or per-file configuration allows to verify the new feature for a particular set of tests. However, enabling new feature often affects other existing tests and may require further adjustments. It is actually good to enable new features for tests as early as possible since it sometimes helps WebKit developers to detect issues they had not initially expected. Right now it happens when the feature is set to DEFAULT_EXPERIMENTAL_FEATURES_ENABLED. IIUC with the current proposal that will now only happen when the feature is removed from the experimental category and hence already considered stable enough for shipping. * Similarly, I wonder what will be the behavior of experimental features in Safari Tech Preview? I think currently they can be on by defaut and hence allows to get early feedback from Web developers. Again they might be affected by a new feature, even when they don't know about it at all (and hence would not try to explicitly enable it). IIUC, with the current proposal, they will always be off by default. * A bit tangential, but I wonder whether we should have a policy to handle web-facing changes. Mozilla and Chromium developers typically send "Intent to implement/ship/remove etc" to their developer mailing lists so that people are aware of the web-facing changes and can discuss them. As previously mentioned, people might only notice a behavior change once the new feature is enabled. IIUC, with the current proposal that will again only happen once the feature is no longer considered experimental. -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc
Hi all, The new behavior is enabled for tests after https://trac.webkit.org/changeset/235806/webkit Essentially, this means that if you want set/get the scroll position of the test pages, you should now just use document.scrollingElement instead of document.body. I'll wait a few days before proposing to set it to DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and allow wider testing : https://bugs.webkit.org/show_bug.cgi?id=189472 Frédéric On 30/01/2018 17:21, Frédéric Wang wrote: > Hi everybody, > > I'd like to announce that I started to implement the behavior for > scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and > scrollingElement [1] as specified by the CSSOM View specification [2]. > > To summarize, the main difference is which element to use in order to > set or get the scroll properties of the viewport in standard > (non-Quirks) mode: > > * The CSSOM View spec says it should be document.documentElement and > most browsers implement it that way. > * Chromium used to use document.body but this has recently been changed > to follow the CSSOM View spec [3]. > * WebKit still uses document.body and I'm proposing to change this behavior. > > Note that this is likely to break existing content. The change was > attempted in WebKit in the past but broke some non-regression tests [4]. > Chromium people also had some issues when trying to ship the change but > things went well at the end [5]. > > For now I'm developing it under a CSSOMViewScrollingAPI developer flag. > I was able to run the tests with that flag enabled, modulo a few test > adjustments. > > [1] https://bugs.webkit.org/show_bug.cgi?id=5991 > [2] https://drafts.csswg.org/cssom-view > [3] > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4 > [4] https://bugs.webkit.org/show_bug.cgi?id=106133, > https://bugs.webkit.org/show_bug.cgi?id=121876 > [5] > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ > ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20 > -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Standard process for exporting new WPT tests?
On 25/05/2018 00:52, Ryosuke Niwa wrote: > > Yes, it's okay for a WebKit commit to merge the change which got > merged into WPT but it's never okay to first commit the test into > WebKit and then later upstream it to WPT... If that's what you meant by "NEVER commit new tests into LayoutTests/imported/w3c/web-platform-tests" then I agree it's very sensible. On the other hand, if someone uploads a patch adding a new test to LayoutTests/imported/w3c/web-platform-tests without the corresponding GitHub PR I would expect that we only cq- this patch and point that person to a link explaining clearly the WPT export process and agreement. -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Standard process for exporting new WPT tests?
Thank you everybody for your replies. So summarizing: * WebKit devs should be able to choose between: - submitting new WPT tests to the GitHub WPT repo first and then importing them to the WebKit repo after they are approved. - OR submitting patches to WebKit Bugzilla first and then exporting them to the GitHub WPT repo. * In any case, you should never land a test into the WebKit repo before the corresponding test has successfully landed into the GitHub WPT repo. * We now have Tools/Scripts to import and export WPT tests. In particular the latter script ensures that the previous condition is satisfied. I believe a wiki page to explain the process for adding WPT tests to WebKit should be accessible from https://trac.webkit.org/wiki#LayoutTests so that with have a centralized documentation people can refer to. Maybe this could be the following one but it was last updated three years ago and does not mention the latest tools/agreements/work-in-progress: https://trac.webkit.org/wiki/WebKitW3CTesting -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Standard process for exporting new WPT tests?
On 23/05/2018 22:50, Ryosuke Niwa wrote: > As we have preciously discussed, we should NEVER commit new tests into > LayoutTests/imported/w3c/web-platform-tests. > I don't understand this comment. Can you please elaborate or indicate where this was discussed? We have used the import script exactly to import/update WPT tests into LayoutTests/imported/w3c/web-platform-tests (and in particular add new tests). Also I understand Youenn's export script is supposed to allow committing new tests to LayoutTests/imported/w3c/web-platform-tests and upstreaming them to WPT. -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Standard process for exporting new WPT tests?
Hi all, When implementing new platform features in WebKit, some of us write new WPT tests in order to verify spec conformance. One of the reason to use this format is that the tests can then be easily shared with web engine developers and people involved in standardization, an important feature for web platform developers. Youenn has shared various ideas to export such WPT tests to the W3C GitHub repository in the past [1] [2] [3] but I'm not sure the WebKit community has reached an agreement. There are basically two ways to proceed: 1) Either submit WPT tests to GitHub (or Mozilla / Chromium) repository, get them reviewed and do the import within the patch that implements the feature in WebKit. 2) Or submit the patch with new WPT tests to WebKit, get it reviewed and export it to GitHub (later sync with Mozilla / Chromium). The first option has the advantage to get more people involved in test review, which sometimes gives faster replies or useful advice from people who more familiar with the spec. However, the second option has the advantage of not splitting the coding & testing parts and is better for the WebKit implementers and reviewers. That latter option also aligns with what Mozilla and Chromium developers do. Can we please agree on a way to proceed? And add documentation somewhere for developers/reviewers? Thanks! [1] https://lists.webkit.org/pipermail/webkit-dev/2017-March/028884.html [2] https://lists.webkit.org/pipermail/webkit-dev/2017-April/028932.html [3] https://lists.webkit.org/pipermail/webkit-dev/2017-December/029837.html -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Tips to build faster on Mac?
On 27/03/2018 18:16, Dan Bernstein wrote: > > >> On Mar 27, 2018, at 9:07 AM, Frédéric Wang <fw...@igalia.com >> <mailto:fw...@igalia.com>> wrote: >> >> I see that the make command allows to make incremental builds for >> macOS. Does anyone know how to specify that we want to build for the >> iOS Simulator? > > Add SDKROOT=iphonesimulator to the make invocation. That works, thanks! -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Tips to build faster on Mac?
On 23/03/2018 23:08, Danyao Wang wrote: > Thanks everyone! I had a chance to try plain "make d -C > Source/WebCore" today and it's a lot faster. Small changes build under > a minute, so this is very helpful! > > On Fri, Mar 16, 2018 at 12:40 PM, Maciej Stachowiak <m...@apple.com > <mailto:m...@apple.com>> wrote: > > > You can also just cd to the WebCore directory and type make. > >> On Mar 16, 2018, at 3:24 PM, youenn fablet <youe...@gmail.com >> <mailto:youe...@gmail.com>> wrote: >> >> If you have a full build and made changes to WebCore, you might >> only need to recompile WebCore. With make for instance, one can do: >> make d -C Source/WebCore >> >> Y >> >> On Fri, Mar 16, 2018 at 6:55 AM Danyao Wang <dan...@chromium.org >> <mailto:dan...@chromium.org>> wrote: >> >> Thanks Brian for the Xcode UI tip! So far I've always used >> build-webkit. I didn't realize there could be a difference. >> >> On Thu, Mar 15, 2018 at 6:01 PM, Brian Burg <bb...@apple.com >> <mailto:bb...@apple.com>> wrote: >> >> >> >> > On Mar 15, 2018, at 1:58 PM, Danyao Wang >> <dan...@chromium.org <mailto:dan...@chromium.org>> wrote: >> > >> > Hi, >> > >> > Being new to WebKit development (and also switching >> from Linux to Mac), I find my workflow relatively clumsy. >> Building on a fresh checkout usually takes me 20+ minutes >> even on my 12-core Mac Pro. Fastest incremental builds >> are ~2 minutes. This adds a lot to the develop / test / >> debug cycle. >> >> These build times seem normal. WebKit is a big project, >> and we don’t use CMake/ninja by default when building for >> Cocoa ports. >> >> Are you building via build-webkit on the command line? In >> my experience, incremental builds are faster via Xcode’s UI. >> >> > I heard the good folks from Igalia working on the GTK >> port use icecc. Has anyone used this on Mac? Any other >> productivity tips? >> > >> > Thanks! >> > Danyao >> > ___ >> > webkit-dev mailing list >> > webkit-dev@lists.webkit.org >> <mailto:webkit-dev@lists.webkit.org> >> > https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev Hi all, I see that the make command allows to make incremental builds for macOS. Does anyone know how to specify that we want to build for the iOS Simulator? Thanks! -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc
On 30/01/2018 17:21, Frédéric Wang wrote: > Chromium people also had some issues when trying to ship the change but > things went well at the end [5]. > > [5] > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ > ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20 I am told by Chromium developers that the workaround they had to introduce for smoothscroll.js won't be necessary for WebKit, because we don't have "chrome" in the UA string. Of course that does not mean that the behavior changes won't cause any other issue... -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc
Hi everybody, I'd like to announce that I started to implement the behavior for scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and scrollingElement [1] as specified by the CSSOM View specification [2]. To summarize, the main difference is which element to use in order to set or get the scroll properties of the viewport in standard (non-Quirks) mode: * The CSSOM View spec says it should be document.documentElement and most browsers implement it that way. * Chromium used to use document.body but this has recently been changed to follow the CSSOM View spec [3]. * WebKit still uses document.body and I'm proposing to change this behavior. Note that this is likely to break existing content. The change was attempted in WebKit in the past but broke some non-regression tests [4]. Chromium people also had some issues when trying to ship the change but things went well at the end [5]. For now I'm developing it under a CSSOMViewScrollingAPI developer flag. I was able to run the tests with that flag enabled, modulo a few test adjustments. [1] https://bugs.webkit.org/show_bug.cgi?id=5991 [2] https://drafts.csswg.org/cssom-view [3] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4 [4] https://bugs.webkit.org/show_bug.cgi?id=106133, https://bugs.webkit.org/show_bug.cgi?id=121876 [5] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20 -- Frédéric Wang - frederic-wang.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit
On 28/11/2017 16:24, Philip Jägenstedt wrote: > > To do the upstreaming from WebKit first would get around this problem, > and is something I could see us doing. If a Chromium developer > upstreamed tests from WebKit and got review from a WebKit reviewer, I > think we would rubberstamp the corresponding removal in Chromium. > > But that would be a futile exercise if the WebKit reviewers don't want > to delete the tests from WebKit. The only remaining options would then > be not sharing the tests with EdgeHTML and Gecko, or creating more > duplication for WebKit. Note that we can also have duplication in WebKit but for each port decide which version will be executed by adding "skip" tags in TestExpectation. Not ideal in my opinion, but that would allow e.g. GTK/WPE ports to run the latest WPT tests while macOS/iOS ports keep the legacy LayoutTests/ versions / history. -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit
On 17/11/2017 17:23, Maciej Stachowiak wrote: > I should also note that pulling in the test suite won't automatically > get the bugs fixed or prioritized, or even filed in the bug tracker > necessarily.eratwerATWeRTWAerATWertwAerer Sure. However, I believe in general having more people importing the WPT tests and trying to match the behavior of the spec and of other browsers would help, if only to be aware of issues (as Philip mentioned we could also improve notifications etc). In the particular cases I mentioned https://bugs.webkit.org/show_bug.cgi?id=162668 was reported one year ago after Khaled Hosny (invited expert for the WebFonts WG) fixed the bug in the GTK port while https://bugs.webkit.org/show_bug.cgi?id=179237 just requires to backport the changes in Chromium to match the latest WebVTT spec. These are of course only two examples, but in general more tests shared with the rest of the Web Platform community (developers and spec authors) are very useful for improving WebKit and interoperability. > I find it super convenient that EWS runs all the tests even on WIP > patches. It often catches test failures in tests I didn't think to run > myself. I think it would be great if EWS could run tests on more > platforms. Just running release regression tests on more platforms > would be a big win, if debug builds are the gating factor. I guess it > would be kind of neat to have a feature of "run the tests across all > configurations, but only some of them". But I don't think I would > prioritize it over having more kinds of tests, or finding ways to make > the full test suite run faster. Right, running all the tests is nice. But sometimes I personally feel guilty to have to execute everything on EWS for example to retrieve results for macOS/iOS (when I did not have access to a mac) or to fix compilation failures on Windows ports. So better granularity would be helpful in my opinion. In any cases, this was just one idea and people working on CI and infrastructure are in better position to know how to improve running time of WPT tests. I'm surprised that I don't hear such complaints from Mozilla and Chromium (but maybe I'm not aware of them). -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit
On 17/11/2017 16:26, Maciej Stachowiak wrote: > WebKit has a lot of tests that were regression tests for a specific > bug fix, not as conformance tests (though they might b useful for that > too). In such cases, the association with the bugs.webkit.org bug is > more important than the spec URL. That’s particularly the case when > the test has been changed multiple times to reflect further WebKit > behavior changes. I know that I’ve personally found it very useful to > look at revision history of tests, or search for bug numbers or > keywords in LayoutTests/ChangeLog to find related tests. > Not saying this is the sole purpose of tests, but losing this ability or > making it more awkward would be a downside to deleting tests from the WebKit > repo. Well, I think we agree here, that's why "conformance" tests was specified in my message. For such tests, connecting the history of tests with the development of the specs is actually more important. For example I recently noticed that some bugs with WOFF2 (on Apple's ports only) and WebVTT have been ignored in WebKit because we don't import/sync WPT tests for these specs. > Maybe I’m missing something, but isn’t that already how it works in WebKit? > EWS and buildbot run all the tests, but on your own machine you can get > run-webkit-tests to run any subset you want. Not everybody has the hardware to produce debug builds of WebKit on all existing ports and run a big amount of tests :-) AFAIK, EWS run all the builds as well as all the tests on macOS/iOS, you don't have options to select a subset of the tests or the ports. Buildbots run all the builds & tests on all platforms *after* a patch lands in the main repo. So we do too much for WIP patches (extra runtime cost I'm mentioning here) and not enough to check the final patch before landing (which causes different issues like extra rollout or gardening commits or difficult regression bisecting). -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit
Hi Philip, We (at Igalia) are strong supporters of WPT tests and we've appreciated a lot the effort made by Youenn and others to make them possible in WebKit. They are very important for interoperability and make life much easier for developers working on different WebKit ports and different Web engines. Ideally, we believe that future conformance tests in WebKit should be written using the WPT format and submitted to web-platform-tests repository (of course there are exceptions when the WPT API is too limited). WPT tests have references to spec URLs and their own git history, so it should always be possible to know why they have been written. This also reduces review cost on WebKit's side, as test review can be done by experts in the relevant specs. Probably it would be nice to convert old tests to WPT and check duplication to avoid increasing runtime cost but that's indeed going to be a big effort. It could also be possible to improve how the CI tests are executed in the WebKit project, taking inspiration from Chromium or Mozilla projects (i.e. run all tests before a patch lands in the main repo, but allowing devs to run a relevant subset during development). In any case, Igalia definitely supports this proposal and is happy to help where possible. Frédéric, for Igalia's Web Platform Team signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 25/10/2017 19:05, Maciej Stachowiak wrote: > > (1) Is it at all common to use MathML with a math font specified as a web > font? Can you give an example? I can't say whether it is "common" but I guess the trick is well known by MathML users, since unfortunately many systems do not provide math fonts by default. I have a github repo with known fonts at https://github.com/fred-wang/MathFonts As an example Jacques Distler uses STIX 2 WOFF on his blog: https://golem.ph.utexas.edu/~distler/blog/archives/002702.html https://golem.ph.utexas.edu/~distler/blog/styles-site.css Some people also bundle WOFF fonts in web apps or ebooks. Web fonts are also used by browser addons e.g. https://addons.mozilla.org/en-US/firefox/addon/mathml-fonts/ which allow to workaround the lack of system fonts (and the impossibility to install them for users). Website using MathML often have a page with installation instructions for math fonts, for example on NIST dlmf: http://dlmf.nist.gov/help/mathml#S3 Note that I've seen similar things (WOFF fonts, addons, instructions) for other languages in the past e.g. https://addons.mozilla.org/en-US/firefox/addon/khmer-fonts-package/, so again it's not specific to math. > (2) Is it at all common to use MathML only to the extent that it's rendered > fine without a math font? Again, I'm not sure how common it is but I've seen some users happy with basic MathML rendering for elementary calculations. I was also surprised to see some people excited about my CSS stylesheet at https://github.com/fred-wang/mathml.css that can render very basic math. There are a lot of such formulas on Wikipedia, for sure for instance https://en.wikipedia.org/wiki/Fraction_(mathematics) contains MathML formulas that can be rendered without specialized math fonts. > (3) In the cases above, is there usually an image fallback? It really depends on the website. But definitely people using MathML need some fallback (image, CSS layout, javascript layout, text etc). How this fallback is triggered depends on the website, there is not any real rule. IIUC, the argument mentioned earlier only considers the case where an author would try to detect MathML support and automatically fallback to an image otherwise. As I said, authors could also try to detect availability of math fonts, or provide WOFF fallback (Distler's blog), or have a page to explain how to install fonts (e.g. NIST dlmf), or use image by default and explain how to enable MathML & install fonts (e.g. Wikipedia), or provide LaTeX fallback in an (my blog) or... IMHO, platform owners should not speculate on what authors will do. Disabling MathML just because of the lack of math fonts, does not seem a good idea. On the one hand, if MathML is enabled page authors can still decide to serve fallback content if they think the support is not good enough on the user platform. On the other hand, if the platform owner has disabled MathML, then there is no way for users/authors willing to use MathML to force it to be enabled again... > Why don't we wait to hear from port owners whether they would actually want > to disable MathML for reason of compatibiltiy. Knowing answers to the above > questions would help. Sure. My email was to follow-up on https://bugs.webkit.org/show_bug.cgi?id=177744 and the discussions at the Web Engines Hackfest, so they are not forgotten. But there is no hurry to remove the build flag for now. -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 24/10/2017 18:50, Maciej Stachowiak wrote: > I don't have a strong opinion on whether we should support disabling > MathML. My point is just that if we support disabling it, it should be > a runtime switch, not compile-time. > Good reasons to have a compile-time switch would be: > - Some ports want the code size savings > - It requires back-end code that is not available on all ports > > But neither of those is true. > > On the other hand, we might still want a runtime switch if some ports would > like to disable the feature for reason of compatibility based on available > fonts. I think it's up to port owners to say whether they want to disable the > feature for this reason. Hi, I believe it is up to the platform owners to decide whether they want to provide math fonts by default ; depending on whether they want to privilege disk space or a better user experience. However, I still don't see the connection between available fonts and enabling MathML support. As I said, some pages with MathML provide the necessary WOFF math fonts while others just use basic math (fractions etc) where the default text fonts are enough. So the owners would be intentionally breaking these pages, just because they don't provide math fonts on their platforms ? That sounds weird, to me. Also I think a runtime flag makes sense for the use case of the Tor project, but it is a separate use case IMHO and it should not be blocking the removal of the compile-time flag. So to summarize, I'm happy to submit a patch to remove ENABLE(MATHML) if the only reasons were the two points you mention (which as you said are not true here). However, if some port owners provide a concrete explanation of why they want to keep the option of disabling MathML then I don't think I'll have time to check the runtime option right now, so I'll just keep the status quo and it will be up to these people to submit a patch or to keep fixing the build failures for --no-mathml ;-) -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 24/10/2017 11:35, Olivier Blin wrote: > Hi, > > The difference is about 250 kB on libWPEWebKit.so.0 for a WPE build on > my ARMv7 target: > > - without MathML : 37474160 > - with MathML: 37726056 > > This can still be significant on low-end devices, with 128 MB of flash > storage. > Thank you Olivier. That indeed seems to match Adrián's guess of "a few hundreds of kilobytes". -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 24/10/2017 09:14, Frédéric WANG wrote: > so it's a different use case and that one does not make sense to me. *does make sense* -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 23/10/2017 18:25, Adrian Perez de Castro wrote: > From your description it sounds that what takes more disk space in MathML are > the needed math fonts, and that the amount of code added to WebKit when built > is in the order of hundreds of kilobytes, at most (BTW, do you have figures of > MathML enabld vs. disabled to confirm?). That being the case, it seems fine to > me that MathML support is always enabled. > > Usually my main concern with removing compilation guards is forcing additional > usage of megabytes of disk and/or memory in embedded platforms (which is, for > example, the case for ENABLE_VIDEO: for the GTK+ and WPE ports it completely > avoids the GStreamer dependency, which saves tens of megabytes!). But keeping > the guards to save just a few hundreds of kilobytes is certainly not worth it, > and in this case embedders can choose to not ship the math fonts. > > TL;DR: Fine by me, as it seems the compile flag only saves a few kilobytes in > the built binaries, and the math fonts can't be skipped anyway by embedders. > > Best regards, > > > -- > Adrián Thanks Adrián. No, I wanted to do it during the Web Engines Hackfest but did not have time to try. Also, Olivier mentioned he would check the difference and tell whether it is significant or not for his project, but I have not heard back from him yet. -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 23/10/2017 18:11, Maciej Stachowiak wrote: > > Is there any way we can convert MathML to a runtime switch? It seems > like the main consideration is rendering quality given available > fonts, rather than code size. > > Regards, > Maciej > @Maciej: As I explained, I don't think disabling a HTML5 feature to determine which kind of fallback content will be delivered to the user is a good idea. Authors can provide Web fonts and for very elementary math (e.g. using only simple fractions) you even do not need math fonts at all. Anyway, replying to your question the Tor project also added run-time preferences for MathML and SVG in Gecko last year: https://hg.mozilla.org/mozilla-central/rev/0d48c28cc547 https://hg.mozilla.org/mozilla-central/rev/7b09464eb767 IIRC, they basically move the MathML/SVG elements in "unknown" namespaces so that the MathML/SVG content and layout classes are not used to process them. I believe we could do the same for WebKit. Note that their justification is security (users intentionally disable HTML5 features to "reduce attack surface area") so it's a different use case and that one does not make sense to me. In any cases, I do not think adding an runtime option for MathML/SVG is a prerequisite to remove the build-time option, as the latter was more about reducing binary size/dependencies for web engines developers while the former was about providing more control to users. -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
@Konstantin I think you are a bit deviating from the main question but FWIW: a) MathML also remains readable without math fonts as long as you don't use complex content (same is true for normal text as long as you do not use the rarest unicode characters) b) None of the feature detection technique is perfect (mspace only tests a very basic MathML feature, one can also make a test for available math fonts if present, what if javascript is disabled? etc) and adding a build-time flag to disable a HTML5 feature seems a very fragile way to guarantee the content delivered to users. SVG and MathML are features that share a common history (designed as elements in a different namespaces, separate spec embedded in HTML5, initially implemented under a build-time flags in Gecko and WebKit...) so my point was really just that from the implementer point of view it makes sense to handle them consistently, nothing more. It seems you did not reply to the question about whether you have a concrete use case of an embedded device where degrading HTML5 support to help feature detection is important. I suspect for such device like set-top box kind where math rendering is not essential, it does not really matter whether MathML is enabled or not or whether fonts or installed or not. But in any case, I still don't see why a build-time flag would help and, as Maciej mentioned; it could better be a runtime flag instead. -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
On 23/10/2017 18:04, Konstantin Tokarev wrote: > There is a big difference between SVG and MathML: the first one is entirely > self- > contained, while (AFAIU) MathML requires presence of math fonts on the target > system for correct rendering (i.e. native MathML will look much worse than > image > fallback that is usually available). > > Imagine embedded system (e.g. of set-top box kind) which has no math fonts on > the board. Will always-on MathML be progression or regression there? SVG also requires fonts for the tag. And Web fonts exist to work around the lack of system fonts. As a Web Platform developer, I believe browser sniffing is bad practice, so I hope people use other techniques to provide alternate content. Do you have any concrete use case in mind? -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: Remove ENABLE(MATHML)
Hi, There have been some discussions recently on https://bugs.webkit.org/show_bug.cgi?id=177744 regarding the relevance of the compile-time flag for MathML. Discussing with Olivier during the Web Engines Hackfest, it seems he only had disabled MathML in his project because he thought it would reduce binary size. However, he was not really sure this actually had a significant impact. AFAIK, the only dependencies needed for MathML are the font libraries but they are already used for text layout. The implementation is only a few element/rendering files plus some changes here and there. I'm wondering if other people use the --no-mathml build option and believe they really need it? If not, I'm propose to remove this compile-time flag. As a comparison, the flag for SVG was removed in https://bugs.webkit.org/show_bug.cgi?id=127991 ; Mozilla also removed compile time option for MathML and SVG a long time ago ( https://hg.mozilla.org/mozilla-central/rev/b8664f450508 for the former). -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running Safari on the simulator
Hello, Just for the record, this is now fixed in https://trac.webkit.org/changeset/223234 -- Frédéric Wang - frederic-wang.fr signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running Safari on the simulator
On 28/09/2017 04:57, Daniel Bates wrote: > Please file a bug. > > Dan Done: https://bugs.webkit.org/show_bug.cgi?id=177595 -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running Safari on the simulator
On 27/09/2017 19:24, Alex Christensen wrote: > When I want to use the public iOS SDK for WebKit on iOS, I refer to > Dan’s blog post > at https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ > We have bots using this configuration and they’re working successfully > at https://build.webkit.org/waterfall?category=iOS > Maybe you forgot to run configure-xcode-for-ios-development > I did run configure-xcode-for-ios-development indeed (otherwise the build fails IIRC). Also I forgot to say that I can use run-webkit-tests --ios-simulator (which I guess is what is used on bots). My problem is with run-safari --ios-simulator, which has stopped working recently. Thanks, -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Running Safari on the simulator
Hello, I've recently upgraded XCode and rebuilt Safari but when I try running Safari on the simulator, I get the following errors: Tools/Scripts/build-safari --ios-simulator --debug Tools/Scripts/run-safari --ios-simulator Quitting and launching iOS Simulator... Installing /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/Applications/MobileSafari.app. An error was encountered processing the command (domain=NSPOSIXErrorDomain, code=2): Failed to install the requested application An application bundle was not found at the provided path. Provide a valid path to the desired application bundle. Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546. I can not find any MobileSafari.app in my WebKitBuild directory nor in the /Applications/ directory calculated by webkitdirs.pm ; trying to hardcode a different path in webkitdirs.pm I instead obtain: Quitting and launching iOS Simulator... Installing /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Applications/MobileSafari.app. An error was encountered processing the command (domain=IXUserPresentableErrorDomain, code=2): This app was unable to be installed. Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546. Did anyone experience the same issue? -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Building WebKit for an iOS device
Le 12/07/2017 à 19:19, Alex Christensen a écrit : > WebKit can be built and run on the iOS simulator by anyone with the > public iOS SDK. I > use https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ when > I forget how to do this. > > I guess WebKit can be built for device, but I’m pretty sure WebKit > cannot be put as the system framework on an iOS device without > Apple-internal tools. With a lot of work you might be able to > statically link everything into a custom app for local debugging, but > I’m pretty sure such an app would be rejected by the App Store based > on section 2.5.6 > of https://developer.apple.com/app-store/review/guidelines/ > Yes, I'm already using the simulator for running tests and testing local ios builds. I was just wondering whether it was possible to produce and install a local build for development and testing purpose on a device. Apparently from your reply and Michael's this seems quite unlikely with the public iOS SDK :-( I guess it would be nice to mention this limitation on https://webkit.org/building-webkit/ Thanks. -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Building WebKit for an iOS device
Hello, For development and testing purpose, I was wondering if there is a way to produce a build of WebKit/Safari-mobile and to install it on a device (instead of using the iOS simulator)? And is there any specific requirement like having an Apple developer license and a registered device? I know that we have a builder [1] and I just noticed the "--ios-device" parameter for the build-webkit script but I can't find any information on the official documentation [2] or on the WebKit wiki. I also tried searching this mailing list about the topic but could not find any relevant thread. Thanks, Frédéric [1] https://build.webkit.org/builders/Apple%20iOS%2010%20Release%20(Build) [2] https://webkit.org/building-webkit/ signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Review of patch to support iframe's allow-popups-to-escape-sandbox?
Hello, Last month I uploaded a patch to support the allow-popups-to-escape-sandbox flag for iframe's sandbox attribute [1]. As suggested by its name, it allows popups to escape sandboxing. I tried to cc' people or find a reviewer on irc, but was not really successful so far :-( Can anyone please take a look? It seems that a bug with security involvement was fixed last year: Basically popus were never sandboxed [2]. I see that the allow-popups-to-escape-sandbox flag changes that behavior when it is explicitly requested by the page's author, so I guess some careful review (from Apple?) might be required here. Thank you, Frédéric [1] https://bugs.webkit.org/show_bug.cgi?id=158875 [2] https://trac.webkit.org/changeset/204266 -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Recommended MathML fonts on WebKit platforms
Le 13/03/2016 à 20:57, Darin Adler a écrit : > 1) To make MathML work really well, platforms need to include appropriate > fonts. As you said, this is not a WebKit decision, but a decision made by > platform owners. If we want to advise them about the importance of this, it > would be good to draft something explaining how we, the WebKit project, see > this requirement and give advice on what to do. Someone should write a draft > of this recommendation so we can put it somewhere on webkit.org, and also so > we can discuss and make sure we agree on this advice. I’d like to see this > written in the form of a recommendation so we can see if this is really a > practical request. To give one example, “please use STIX Math, but version 2 > which is not out yet” isn’t a great recommendation. Hi all, Last year, I had written some description of math fonts for MathML rendering [1]. I'm resurrecting this discussion since "STIX Two" was released last December with a complete redesign of the text portion [2]. "STIX Two Math" is now usable by WebKit for MathML rendering and is included in the default stylesheet after [3]. Among available options, "STIX Two Math" provides the best coverage for unicode characters and stretchy math operators. Also, some users prefer it over the more traditional Computer Modern style of LaTeX systems [4]. I believe it would greatly improve user experience if STIX Two was pre-installed on WebKit platforms. And as discussed in the original thread, this would also help for MathML testing on mac. (FYI, there are some bug entries to upgrade the STIX package of Linux distributions. I also just updated my macOS Sierra to 10.12.2 but the bundled STIX fonts are still from the obsolete & deprecated STIXGeneral set...) [1] https://trac.webkit.org/wiki/MathML/Fonts [2] http://www.stixfonts.org/ [3] https://bugs.webkit.org/show_bug.cgi?id=165676 [4] https://golem.ph.utexas.edu/~distler/blog/archives/002926.html#more -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ./Tools/Scripts/run-safari doesn't work with Safari 10
Hi Marco, You might want to check https://trac.webkit.org/wiki/WebKitNightlyElCapWorkaround In particular "If you want to use run a custom build, instead of using run-safari (as usual), you'll need to set DYLD_FRAMEWORK_PATH and run SafariForWebKitDevelopment manually. " Hope that helps, Frédéric Le 18/07/2016 à 22:02, Marco Barisione a écrit : > Hello, > > I recently installed Safari 10 on some machines running 10.11.6 DP. > Unfortunately, I cannot get Safari 10 to work with WebKit compiled from SVN. > > I tried with both SVN trunk (from today) and the revision tagged in SVN that > corresponds to my currently installed Safari (602.1.38.4). > I compiled Safari with the usual: > > $ ./Tools/Scripts/build-webkit > > And then I tried to run Safari with: > > $ ./Tools/Scripts/run-safari > > Safari 10 starts, but nothing loads probably because it cannot load its > injected bundle. This is the output: > > Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to > built WebKit in /Users/bari/src/webkit/WebKitBuild/Release. > 2016-07-18 14:18:32.900 SafariForWebKitDevelopment[424:4918] [Keychain] > SecItemCopyMatching failed fetching extension list with error -34018 > 2016-07-18 14:18:32.923 SafariForWebKitDevelopment[424:4918] [Keychain] > SecItemCopyMatching failed fetching extension list with error -34018 > 2016-07-18 14:18:33.091 com.apple.WebKit.WebContent.Development[425:4983] > Error loading > /System/Library/StagedFrameworks/Safari/Safari.framework/Safari: > dlopen(/System/Library/StagedFrameworks/Safari/Safari.framework/Safari, 265): > Symbol not found: _OBJC_CLASS_$_WBSCompletionListRankingObserver > Referenced from: > /System/Library/StagedFrameworks/Safari/Safari.framework/Safari > Expected in: > /System/Library/PrivateFrameworks/SafariShared.framework/Versions/A/SafariShared > in /System/Library/StagedFrameworks/Safari/Safari.framework/Safari > InjectedBundle::load failed - Could not load the executable from the bundle. > > > I’m a bit surprised that I couldn’t find anything about this problem in > bugzilla, IRC or on this mailing list. > Am I doing something wrong or is this a problem with newer Safari? Is there > any fix/workaround for this? > > Thank you! > signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Use #pragma once instead of header guards
FYI, I just performed that change as part of a general cleanup of MathML headers: https://trac.webkit.org/changeset/203228 The code style guidelines still mention the old-style header guards so it should probably be updated: https://webkit.org/code-style-guidelines/#names-header-guards Le 10/03/2016 à 02:27, Anders Carlsson a écrit : > Hi floks, > > Currently we use > > #ifndef Header_h > #define Header_h > > … > > #endif > > I propose that we instead start using > > #pragma once > > which does the same thing. It can be faster on some compilers, is less error > prone and is one line instead of three! All compilers we use support #pragma > once. > > Thoughts? > - Anders > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] MathML refactoring: Project Complete!
Hi WebKit developers, We are happy to announce that we are done with the MathML refactoring proposed last December [1]. The first phase was a big clean up of the MathML implementation and you can find details in a first blog post [2] but essentially: * MathML renderer classes now derive from RenderBlock instead of RenderFlexible (except RenderMathMLTable which still derives from RenderTable) so we no longer interfere with the flexbox code. * MathML renderer classes do not create anonymous renderers any more (except RenderMathMLFenced which creates anonymous RenderMathMLOperators) so the render tree essentially matches the DOM tree. * MathML renderer classes now perform simple box layout (again except for RenderMathMLTable and RenderMathMLFenced) and should be much more consistent with the rest of the WebKit code. Many MathML rendering bugs have been fixed as an immediate consequence of this clean up. But it also became much easier to follow OpenType MATH & TeX rules for layout [3] and to implement important MathML features. This has been done in a second phase and you can find details on the MathML improvements in a second blog post [4]. During the development, we also decided to include a third phase: Moving the parsing of MathML attributes into the DOM classes instead of doing it in the renderer classes. This has only been partially achieved but could be addressed in future developments. For those who are interested, it is tracked in [5]. Finally, we tested the rendering on GTK, EFL, OS X and iOS ports and it seems good. The status of the Windows port is unknown. We expanded the test suite with more MathML tests and performed some gardening: * All the tests pass on the GTK bots. * All but the mismatch tests pass on EFL bots (it's not clear whether screenshots are correctly taken). * As discussed in a previous thread, OS X and iOS bots lack pre-installed math fonts [6] and these fonts are not whitelisted by the test runner. Most of the failures were due to tests requiring such math fonts and so these tests are now skipped. * The Windows port also has several unexplained failures but someone should analyze that more carefully. We plan to continue MathML developments in the future including finishing some refactoring (RenderMathMLTable, attribute parsing...) and improving MathML support and rendering quality. Thank you again to all the people who made this contribution possible! Frédéric, for the Igalia's Web Platform Team [1] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring [2] http://frederic-wang.fr/mathml-refactoring-in-webkit.html [3] http://www.mathml-association.org/MathMLinHTML5/ [4] http://frederic-wang.fr/mathml-improvements-in-webkit.html [5] https://webkit.org/b/156536 [6] https://trac.webkit.org/wiki/MathML/Fonts signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of the MathML layout refactoring
Le 14/12/2015 à 19:39, Zalan Bujtas a écrit :
> It’s great to hear that MathML is getting some proper cleanup. I think the
> proposal sounds good and I am looking forward to the patches.
>
> Minor observation: I noticed that, since MathML block is no longer a flexbox,
> but it still needs some of the flexbox functionality, the following pattern
> has been introduced to the generic renderbox/block code.
> -if (parent()->isFlexibleBox()) {
> +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> I just wish there was another way to handle this.
>
> Zalan.
Hi Zalan,
The final patch to move away from flexbox is now ready for review:
https://bugs.webkit.org/show_bug.cgi?id=153991
A patch based on Alex's initial attempt is still available and as you
can see we don't need to duplicate all of these RenderFlexibleBox
functions any more. We still need some minor adjustments to make
RenderMathMLBlock inherits from RenderBlock, though. In particular,
regarding the 4 changes in RenderBox you mentioned we actually still
need to keep two of them because MathML renderers shrink to fit their
content instead of occupying the width of their container.
Regards,
Frédéric
signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Status of the MathML layout refactoring
Hi all, Last December, Alex wrote an announcement about some refactoring of the MathML layout code [1]. We slightly deviated from the plan proposed there: the two separate steps (Remove FlexBox dependency without changing the RenderTree structure and then Refactor the RenderTree structure) are now expected to be done in a single phase. We also added more phases: Adding support for important MathML features and OpenType MATH properties ; and Moving all parsing of MathML attributes from renderer classes to element classes. You can get a detailed explanations and status on the trac wiki [2]. As you can see we have already merged many patches of phase 1 and we are close to make MathML independent from flexbox. We would definitely welcome any help to complete that work as soon as possible... So if some of you have time to review these patches or at least provide feedback, that would be much appreciated! Note that this refactoring mainly focuses on code quality so that it is easier to maintain and to add future improvements. However, if you are curious about how mathematical formulas will look like after the refactoring, see [3] for a screenshot of Mozilla's MathML torture test [4] in Safari, using the Latin Modern Math font [5]. Thanks, Frédéric Wang [1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html [2] http://trac.webkit.org/wiki/MathML/Early_2016_Refactoring [3] http://people.igalia.com/fwang/images/mac-webkitrefactored-latinmodernmath.png [4] https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test [5] The importance of fonts for math rendering has already been discussed in a previous thread. See http://trac.webkit.org/wiki/MathML/Fonts for the latest update. signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG images with foreignObject inside canvas
Le 04/04/2016 22:22, Philip Rogers a écrit : > Hi Frédéric, > > I'm sorry you had to hit this confusing area recently. I just filed > https://bugs.webkit.org/show_bug.cgi?id=156176 which we can use to > track progress on this. > > The core issue is that foreignObject has the potential to leak > information (e.g., visited links), and there hasn't been enough user > interest to justify removing that restriction. Hi Philip, Thank you very much for opening the bug! Yes, I'm aware of this security issue... I did not follow the details when that happened, but Mozilla has implemented support for foreignObject inside canvas for several years and there is an article on MDN describing it: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas Maybe it would be worth checking with them what was their rationale to remove that restriction and if it's worth following the same approach for Blink/WebKit... Frédéric signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] SVG images with foreignObject inside canvas
Hi, After bug 119492, SVG images are allowed inside canvas without tainting as long as they do not contain foreignObject. Two months ago, changeset 195614 landed to make this a bit more secure and the following FIXME comment was added to SVGImage.cpp: // FIXME: Once foreignObject elements within SVG images are updated to not leak cross-origin data // (e.g., visited links, spellcheck) we can remove the SVGForeignObjectElement check here and // research if we can remove the Image::hasSingleSecurityOrigin mechanism entirely. Does anyone know if there is any plan / bug report for this? The FIXME comment misses a bug number, I can not find any bug entry on Bugzilla (only the related bug 91523 and bug 131033) and I don't have access to bug 119492... Thank you, -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fonts for WebKit tests on OS X?
Le 14/03/2016 23:34, Myles C. Maxfield a écrit : > This is because we whitelist an explicit list of fonts which the tests > are allowed to use. We don’t want tests to start failing just because > the user has some unexpected font installed on their system. See > allowedFontFamilySet() in Tools/DumpRenderTree/mac/DumpRenderTree.mm, > Tools/WebKitTestRunner/InjectedBundle/cocoa/ActivateFontsCocoa.mm, and > Tools/WebKitTestRunner/mac/TestControllerMac.mm Yes, that's the files Darin pointed out in his message. I tried it and it worked great, thanks. > We call CTFontManagerRegisterFontsForURLs(… > kCTFontManasgerScopeProcess …) to make the fonts look like they are > installed for just the local process. On iOS, we use the -sectcreate > linker flag to place the font data directly inside the DumpRenderTree > binary. We then create an in-memory CGFontRef backed by these bytes > (the loader will put them in memory for us at process creation) we use > CTFontManagerRegisterGraphicsFont() to make it look like it is > installed. See activateTestingFonts() and activateFontIOS() in > Tools/DumpRenderTree/mac/DumpRenderTree.mm. I verified the fonts in the repo used by OS X / iOS. As I see they are duplicated in two places, their sizes are a few kilo bytes, they are really test fonts (in the sense that they only have some artificial glyphs and features) and no explicit license to restrict the usage (and AHEM is in the public domain). I also see that fonts for specific languages like "Corsiva Hebrew", "Devanagari MT" are in the whitelist so I assume they are used for testing specific scripts. So it seems that to be consistent with what is currently done, real open source math fonts like Latin Modern Math and STIX Math would really go into the list of allowedFontFamilySet but not in the WebKit repo. What makes sense would be to put an artificial font in the repo to test math features, but that's not so much different from the idea of using Web fonts (and it is already done). Anyway, for now I know how I can add custom fonts on iOS / OSX if that turns out to be necessary or just for me to run tests locally ; and Apple developers are aware of how to improve math rendering on their ports. And as I said, I'll come back later on this math font topic when more progress is made. Thank you again. signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fonts for WebKit tests on OS X?
Le 13/03/2016 20:57, Darin Adler a écrit : > I don’t think the size of the font files in the repository is a significant > issue; are the sizes particularly huge compared to the total size of all the > layout tests including expected results? If this was a problem, we could come > up with some other way of having the test machinery download the fonts, but I > think the complexity of that is not justified to solve a problem that may be > a non-problem. My personal preference is to avoid putting (big) binary data inside revision control system and instead generate or fetch them during the build phase. Of course, sometimes you have to be pragmatic and it's more convenient / easier to just put them in the repo. That's what we do for example for the PNG test expectations, even though I don't like polluting the WebKit patches with base64 data :-) In addition, as I mentioned the OpenType fonts use LaTeX Project Public License + Reserved Font Names and SIL OFL (copyleft + RFN) which may or may not be compatible/convenient with the license of the WebKit project. For example, I'm not even sure that with the current license of Latin Modern Math it is possible to create a WOFF version without renaming it... > Aside from the size of the font files, it seems like we have at least three > separate issues: Thanks, I think I basically agree with these three points. It seems that we went far away from my initial question (can we use custom fonts to run Mac tests?). So I guess the next step for me will be to open a new thread describing precisely the different features of MathML / Unicode / OpenType that are used by WebKit, which math fonts support them or not and what fallback we use or can use when math fonts are missing. Maybe I'll wait the MathML refactoring to land and/or STIX2 to be released before continuing the discussion. I'd just like to highlight that in my opinion the rule of thumb would be to treat math as other human languages (e.g. think to what happens with Asian or Arabic scripts, ruby markup, OpenType features for complex text layout etc). For example, just like normal text, CSS can be used on MathML to select a math font and WebKit has to do its best to render equations with that font or another system font and maybe finally a non-font fallback (Gecko even has an internal "math" language to let users customize the default and fallback fonts for MathML). The same idea applies to pre-installed system fonts or layout tests. -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fonts for WebKit tests on OS X?
Le 12/03/2016 17:04, Michael Catanzaro a écrit : > Not sure I agree that WebKit should pull in any particular font > package. I'd prefer to just add some math font that's installed by > default. Other apps will want it too. Sure, that would be even better :-) Even if apps do not support the MATH table, they would at least definitely need good unicode coverage for math & tech characters instead of tofu... > But it seems to depend on a bunch of perl and texlive packages: > ... > I'm hesitant to add texlive dependencies. Mmh, yes that sounds bad. I just checked the fonts-lmodern package on Debian (https://packages.debian.org/stretch/fonts-lmodern) and unfortunately it depends on tex-common which correspond probably to all the perl scripts you are asked to install :-( I don't see why tex-common would be needed for packages that only contain Open Type fonts. However, I suspect it's just that maintainers have not considered a use of Latin Modern Math outside LaTeX so far. Besides LuaTeX/XeTeX/ConTeXt the only open source math rendering engines using OpenType MATH table are WebKit- and Gecko- based applications (although Khaled Hosny plans to add support for this table in GtkMathView and use it for math rendering in LibreOffice). > Also, I don't see it in Font > Viewer, so I guess it requires the fontconfig change suggested by that > wiki page to work, and that would require coordination with fontconfig > upstream. I suspect there is some good reason that texlive fonts are not > available to applications by default? This depends on what distro / maintainer prefers. In Debian-base distro the fontconfig changes are automatically done for Latin Modern Math, but one Arch Linux user told me that their philosophy is rather to always do the minimal setup and let users decide if they want to configure more ; so the fontconfig change is unlikely to be done by default... > Perhaps the easiest solution is to do nothing, and wait for a new STIX > release? I guess that's the easiest solution for Fedora... However, in general I think the best would probably for distros to have font packages independent from texlive that will just install the fonts in more standard system locations and expose them to all apps by default... -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fonts for WebKit tests on OS X?
Le 12/03/2016 02:01, Michael Catanzaro a écrit : > Fred, if these fonts are not preinstalled, is MathML broken for users > in practice? Yes, math fonts are fundamental as long as you start using relative complex math (integrals, big fence & radicals etc) or deliver documents to people used to high rendering quality (e.g. scientists familiar to LaTeX). In the screenshot of my initial message you can see some obvious problems like horizontal brace not stretching or ridiculously small integral... > If so, that would be a good argument for installing the fonts by default. Well that's what I believe too, but apparently OS vendors have not been convinced so far. I hope that can change for Apple when WebKit has better math rendering... I'd already be happy if there is a simple way to use the fonts for Mac testing, but otherwise I guess we should just focus on the GTK port for now and continue to mark MathML tests as failing on other ports... > That's kinda my concern with this Latin Modern Math font we're using > for the GTK port. We're not shipping that in Fedora and I doubt other > distros are either, so if it's needed for MathML to work well, it's > broken for users in practice. Most (all?) Linux distros have TeXLive packages which include Latin Modern Math, XITS Math (a fork of STIX to fix existing bugs), and more math fonts. So it's relatively easy for users to install the fonts. Ideally, the Latin Modern package should be a dependency of WebKitGTK+, which I think I (or Martin Robinson) already asked in the past to some distro maintainers when we added Latin Modern Math to the test environment. In the case of Fedora, the good news is that STIX is installed by default in the normal setup. The bad news is that the current 1.1 release of STIX has many bugs making it bad for math layout albeit not as bad as with the obsolete version shipped in OS X. However, I'm confident the Fedora package will be updated to version 2 when it is released. See (*) for more details, which also gives an overview of the situation in other operating systems. Given the lack of availability of math fonts, workarounds have been considered but they add burden for each actor: 1) Web Engines: add fallback mechanisms e.g. scale transforms to stretch the base size of operators (done in Gecko) or drawing them directly with graphic functions (done in WebKit for radicals) etc However, people used to high rendering quality find this kind of fallback particularly ugly. Other people proposed to ship the big math fonts in the browsers, which I believe would be sad... 2) Users: install fonts themselves or (specifically for mobile platforms) install some browser addon providing them as Web fonts. 3) Authors: provide the math fonts as Web fonts on each website, ebook, Web app etc (*) https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fonts for WebKit tests on OS X?
Le 11/03/2016 22:12, Myles C. Maxfield a écrit : > Just to clarify: you want tests to use some specific fonts, but don’t > want to check the fonts into the repository? Yes. To test some specific OpenType MATH feature we already use our own small fonts (a few kilobytes) loaded as Web fonts. However, for all the other tests with real math fonts (where we want to get reliable rendering and independent of which of these math fonts are installed or not), it's not clear whether the license (compatibility with WebKit's?) or the size (several hundreds of kilobytes) make that possible/judicious. For WebKitGTK+ we have the separate repository of fonts [3] mentioned in my previous mail that ensures Latin Modern Math is available when running GTK tests. > The downside to 1 is that it adds a new (non-obvious) step that all > developers will have to perform every time they install a new > operating system (in addition to any time we bring up a new buildbot). > I would object to making the development environment even more > complicated than it already is. I agree with that. I'd just like to note that: a) From my experience, installing user font in the Apple Font Book does not even seem enough. For some reason, only the pre-installed font are used when running tests... b) As said above, WebKitGTK+ has a special mechanism to setup a jhbuild environment and automate installation of dependencies ; I was wondering if something similar exists for the Apple ports, but apparently that's not the case... > I’m not sure if I’m allowed to publicly discuss my opinions about 2 > (since it is technically an internal matter) but I would expect its > success to be dubious. Yes, I expected that. However, some years ago Apple accepted to install the STIX font version 1.0. So I was hoping that maybe an upgrade to version 2 when it is released would not be asking too much... at least compared to the burden of managing a jhbuild-like mechanism in Apple ports or bundling big fonts into the repo... > Given this, I think the best solution is to check the fonts into the > repository. Layout tests could target these as web fonts using > @font-face, or they could use the same mechanism that we use for > WebKitWeightWatcher (which is a font) to view the font as if it is > preinstalled (without actually preinstalling it). Can you elaborate on what is done for WebKitWeightWatcher? Thanks, Frédéric signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fonts for WebKit tests on OS X?
*TL;DR: Can you please indicate how to add fonts to use for WebKit tests on OS X? This is is needed for existing and future MathML tests (and actually pre-installing them on Mac/iOS would improve user experience).* Dear all, In the context of the MathML refactoring [1], I've recently been reviewing test results on OS X. Unfortunately, many of existing tests or tests that will be added by the current set of MathML refactoring patches require a math font with an OpenType MATH table to work properly. This is not the case of the obsolete STIXGeneral font families that have been installed by default since OS X Lion [2]. Hence for now those tests are just skipped or have incorrect text/PNG expectations. As a comparison, the GTK port uses the Latin Modern Math font to ensure consistent results [3]. I'm attaching a simple test-fonts.html page and I'm providing the screenshots obtained when I use run-safari or run-webkit-tests with a WebKit build integrating the MathML refactoring patches. From this experiment, it seems that run-webkit-tests only use the pre-installed system fonts (STIXGeneral) but not the fonts I installed manually on my Mac. However, the latter are correctly selected with run-safari and then you can see that the rendering of math equations is much better and closer to the TeX references from the MathML torture test [4]. So my question: is there a way to ensure that WebKit tests are executed with specific fonts on OS X without polluting the WebKit repo with big math Web fonts? If the solution is to have these math fonts pre-installed on OS X, then that would also be great to enhance Safari user experience, as shown by the attached screenshots. In that case, this is probably not the business of WebKit developers but I'd like to suggest two math fonts (also reported to Apple some years ago as problems number 16841023 and 17021145): 1) STIX Math [5], which has very good coverage for unicode symbols, is supported by some tech companies, is released under SIL OFL and is the next version of the STIXGeneral font families currently pre-installed on OS X. Unfortunately the current 1.1 release has too many bugs and so is not really usable for math layout, but version 2 will solve them and is claimed to be released "soon". 2) Latin Modern Math [6], which has the Computer Modern style used by default by TeX rendering engines and is used for WebKitGTK+ tests. This font uses the LaTeX Project Public License + a Reserved Font Name clause but the authors expressed their will to release it under SIL OFL, if that can help. Thank you, Frédéric [1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html [2] https://bugs.webkit.org/show_bug.cgi?id=41961 [3] https://github.com/mrobinson/webkitgtk-test-fonts [4] https://developer.mozilla.org/en-US/docs/Mozilla_MathML_Project/MathML_Torture_Test [5] http://stixfonts.org/ [6] http://www.gust.org.pl/projects/e-foundry/lm-math Title: Test fonts Basic font-family test: monospace: A STIXGeneral: A STIX Math: A Latin Modern Math: A MathML Torture test 19: x + ... + x â k times MathML Torture test 14: ( â 2 â x 2 + â 2 â y 2 ) | Ï ( x + i y ) | 2 = 0 Torture test 21: â p  prime f ( p ) = â« t > 1 f ( t ) d Ï ( t ) signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: remove menclose notation radical
Hi everyone,
As said in a previous message, MathML layout refactoring is in progress
[1] and I'd like to use this opportunity to propose removing support for
the menclose notation radical.
More context:
In MathML3 there are three ways to write roots:
1) child1 child2 ... child3 , equivalent to the LaTeX
expression \sqrt{child1 child2 ... child3} i.e. square root of "child1
child2 ... child3".
2) child1 child2 , equivalent to the LaTeX expression
\sqrt[child2]{child1} i.e. "child2"-th root of "child1".
3) child1 child2 ... child3 ,
equivalent to 1)
Currently 1) and 2) share an implementation in the RenderMathMLRoot
class. That implementation relies on anonymous renderers and flexbox
layout and has many issues with dynamic changes of child list, style,
zoom etc. However, I've uploaded a patch to do a complete refactoring of
RenderMathMLRoot in bug 153987 [2] which solves these issues.
The menclose element definitely needs a clean rewriting too. In
particular, 3) is implemented by appending an anonymous RenderMathMLRoot
child in which we put all the other children ; and again dynamic changes
are not handled very well . I have uploaded a patch to bug 155019 [3] in
order to completely rewrite the menclose implementation and I decided to
just remove support for menclose notation radical instead of trying to
reuse RenderMathMLRoot.
I expect this removal to be safe for the users given that (except in
examples and tests) I've always seen 1) preferred over 3) in math
documents. The only rationale for 3) would be to write overlapping
notations (e.g. )
but again I'm not aware of any concrete use case for that and it's
always possible to nest and to get similar rendering.
Finally, note that the accessibility code does expose the radical
notation and my patch for bug 155019 does not affect that code.
I plan to ask the same to Mozilla developers (FYI in Gecko, 1) and 3)
are implemented in the same class but 2) is implemented in a separate
class with duplicate code ; so it would also make sense for them to do a
simplification). In the future, I also plan to ask to the Math WG to
deprecate this notation and this is already done in the current draft of
the MathML in HTML5 implementation note I wrote [4]. Anyway, the MathML
recommendation is not too strict about supporting notation radical:
"Conforming renderers may ignore any value they do not handle, although
renderers are encouraged to render as many of the values listed below as
possible" [5].
Frédéric Wang
[1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html
[2] https://bugs.webkit.org/show_bug.cgi?id=153987
[3] https://bugs.webkit.org/show_bug.cgi?id=155019
[4] http://www.mathml-association.org/MathMLinHTML5/
[5] https://www.w3.org/TR/MathML3/chapter3.html#presm.menclose
signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML layout refactor proposal
1). Moreover, RenderMathMLScripts.[h|cpp] went down from 631 lines to 454 lines i.e. a ratio of 72%. > MathML may not absolutely need all these, but several (like changing the > order for mroot) are very useful, and outlawing floats and columns and margin > collapsing is great for avoiding bugs or unintended interactions with other > code. So again by using flexbox, I think MathML can be thousands of lines > instead of tens of thousands of lines, and will need a lot less new tricky > lines to avoid buggy interactions with existing layout features and voodoo. AFAIK, neither Gecko nor MathJax rely on flexboxes but just absolutely place the math boxes (as we want to do in the new approach) and they are able to get good math rendering. With hundred of lines, you can do a pure CSS implementation (cf https://github.com/fred-wang/mathml.css/blob/master/mathml.css) and that's fine as long as you only expect low quality and limited support. However, users want high-quality rendering similar to what is done in TeX or Microsoft Word and so we need more flexibility to position math boxes. Like for mmultiscripts, you can probably always add more and more nested anonymous boxes but then the code becomes even more complex and we spend too much time maintaining the integrity of the render tree hierarchy instead of just focusing on arithmetic computations and simple rules. > Finally, I'd like to say that I think it's great that you guys are asking for > feedback on this. There are obviously webkit layout and rendering experts > that know a lot more than I do, and I urge you very strongly to try to get > one of them to help you with this design decision. Otherwise someone else in > a few years may delete your code, as has happened to me. :) As Alejandro said, we are going to submit patches for review soon. Additionally, we are really interested in hearing any feedback from WebKit experts on the following implementation note and tests: http://www.mathml-association.org/MathMLinHTML5/ http://tests.mathml-association.org/ Finally, I believe you are seeing the glass half empty if you reduce our work to "deleting your code". I would rather say that the flexbox implementation was an opportunity for developers/users to experiment MathML in WebKit, improve our test suite, get feedback and discuss the pros and cons of that approach. In particular, thanks to your work we have a good idea of what would be acceptable by the Google reviewers in the future. For now, we are just rewriting the MathML layout to address the feedback from the WebKit community and get something better! Such a refactoring happens everytime in software development, so there are no reasons to worry... -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML layout refactor proposal
Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> It’s great to hear that MathML is getting some proper cleanup. I think the
> proposal sounds good and I am looking forward to the patches.
>
> Minor observation: I noticed that, since MathML block is no longer a flexbox,
> but it still needs some of the flexbox functionality, the following pattern
> has been introduced to the generic renderbox/block code.
> -if (parent()->isFlexibleBox()) {
> +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> I just wish there was another way to handle this.
>
> Zalan.
Alex will correct me if I'm wrong, but I think the changes in RenderBox
are just a temporary solution to avoid breaking tests while we continue
to rewrite the MathML layout code. Hopefully, these won't be needed
anymore when we are done.
--
Frédéric Wang
signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How does WebKit accessibility code tell VoiceOver that a page has finished loading?
Hi, When Safari has finished loading a page, VoiceOver plays an ascending three tone sound effect, selects the web document and starts reading the page. I'm trying to reproduce this effect on Firefox for Mac (see https://bugzilla.mozilla.org/show_bug.cgi?id=718637). There is an old message on Apple mailing list indicating that the application listening the notification must actually play the sound. However, that does not seem to reply to the question since Gecko is the sender of the notification, not the receiver: http://prod.lists.apple.com/archives/accessibility-dev/2012/Apr/msg7.html So instead I'm asking on this mailing list, since Gecko must probably behave the same as WebKit. Reading WebKit source code, I found various potential candidate notifications to send to VoiceOver: @"AXLoadComplete" @"AXLayoutComplete" NSAccessibilityFocusedUIElementChangedNotification I tried making Gecko call NSAccessibilityPostNotification with these three events when the page is loaded and rendered but that does not seem to help. The best I obtained is that the focus is now put on the web document once it is loaded. Any ideas about how WebKit accessibility code works here? Thanks, Frédéric Wang signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How does WebKit accessibility code tell VoiceOver that a page has finished loading?
On 10/02/2015 02:00 AM, Darin Adler wrote: > I suggest normal Apple developer support channels. — Darin Thank you Darin. signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reading Open Type tables in WebKit?
Just to repeat what I said on the bug report, in case some Mac people have already tried to worked on that in the past ; the missing FontPlatformData::openTypeTable on Mac is also preventing OPENTYPE_VERTICAL to be enabled on Mac and thus causing test failures for Japanese vertical text tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/TestExpectations#L542 -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding ENABLE_OPENTYPE_MATH to WebCore
Hi webkit-dev, As mentioned in a previous thread (https://lists.webkit.org/pipermail/webkit-dev/2014-March/026373.html), I'm currently implementing the OpenType MATH table in WebKit (and Gecko) in order to improve the MathML rendering. This table is an extension of the TeX's layout rules (appendix G of the TeXBook) and was designed for the math support in Microsoft Word. Support for the MATH table has been implemented in modern TeX engines such as LuaTeX or XeTeX. The table can be edited with fontforge and is available in various math fonts. Finally, it is currently undergoing standardization in the MPEG group. This support will be behind the ENABLE_OPENTYPE_MATH feature define. See: https://bugs.webkit.org/show_bug.cgi?id=130324 References: http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format/call-proposals-isoiec-14496-22-open-font-format-color-font http://www.ntg.nl/maps/38/03.pdf http://www.fontforge.org/math.html The MATH table and OpenType Features for Math Processing (Microsoft's document, not public yet ; ask me if you want to get a copy) -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Reading Open Type tables in WebKit?
Hi all, I'm trying to implement the OpenType MATH table [1] in WebKit in order to improve the MathML support. I've already made some progress and split the work into several steps [2]. For people who are interested, here are some screenshots showing some rendering improvements: http://www.ulule.com/mathematics-ebooks/news/screenshots-31369/ There was already some code in Source/WebCore/platform/graphics/opentype/ to read OpenType tables so I've been able to reuse it for the MATH table. However, this code is not compiled on all platforms. At the moment I'm only able to compile the support for OpenType MATH table with the following condition: USE(FREETYPE) || (PLATFORM(WIN) (USE(CG) || USE(CAIRO))) which I think means it will work on Linux (I tested the EFL and GTK ports) and most Windows platforms (not tested yet). This means that for the Mac port, I can not do better than using big hardcoded tables... That can be a temporary solution, but it would be better to read the font tables directly in order to get support for arbitrary MATH fonts and to make maintenance easier. So I'd like to know if the current font API on the Mac port has some features to load OpenType tables? As a comparison on Gecko, I've used Harfbuzz to read the MATH table and this library is also available on Mac. I heard that Blink was moving to Harfbuzz on all platforms, so I'm also wondering if there are plans to do the same for WebKit? This would allow to support OpenType tables on all platforms... Thank you, [1] MATH table references: http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format/call-proposals-isoiec-14496-22-open-font-format-color-font http://www.ntg.nl/maps/38/03.pdf The MATH table and OpenType Features for Math Processing (Microsoft's document, not public yet ; send me a private mail if you want to get a copy) [2] Bugzilla references: https://bugs.webkit.org/show_bug.cgi?id=130321 https://bugs.webkit.org/show_bug.cgi?id=130322 https://bugs.webkit.org/show_bug.cgi?id=130324 https://bugs.webkit.org/show_bug.cgi?id=130325 -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reading Open Type tables in WebKit?
Hi, Thanks. So to be more accurate, I think all what is needed is to implement FontPlatformData::openTypeTableon Mac to read the raw data: http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/FontPlatformData.h#L219 Indeed, it looks like CTFontCopyTable is what we want. Then the parsing of the MATH table can be done normally using the existing opentype code in WebKit: https://bugs.webkit.org/attachment.cgi?id=226905action=review I'll email you a copy of MATH spec. Le 20/03/2014 17:50, Chris Fleizach a écrit : Hi, In regards to the Mac platform we can use with CTFontCopyTable() with the MATH identifier. Can you email me a copy of the Microsoft document so we can look into it more. Thanks -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11
git seems to work now, thanks. However, http://trac.webkit.org/changeset is now blocked at revision 165462. For some reason, 165462 does not appear on http://build.webkit.org/console but 165463 and 165464 are visible there. Le 12/03/2014 10:12, Mark Rowe a écrit : I’ve just fixed both trac.webkit.org and git.webkit.org. Please let us know if you notice any further issues. Thanks, - Mark On Mar 11, 2014, at 23:53, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Additionally git.webkit.org is stucked too on r165452. Osztrogonác Csaba írta: Hi, something is still wrong with trac.webkit.org, because it thinks that the newest commit is http://trac.webkit.org/changeset/165452 , but the newest is r165460. Could you check what happened? Thanks. Ossy Lucas Forschler írta: Hello Webkit developers, Apple will be upgrading our network infrastructure starting Tuesday morning at 8am. The webkit.org services will be affected for approximately 4 hours. This includes all *.webkit.org domains. We expect them to be back online before 12. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11
Le 12/03/2014 11:06, Osztrogonác Csaba a écrit : Frédéric WANG írta: git seems to work now, thanks. However, http://trac.webkit.org/changeset is now blocked at revision 165462. Maybe the post commit hook is still broken. That seems to work now. For some reason, 165462 does not appear on http://build.webkit.org/console but 165463 and 165464 are visible there. Because r165462 wasn't committed to trunk, but releases/WebKitGTK/webkit-2.4 branch. It isn't bug. Ah, OK thanks. -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Tracking WebKit changes needed documentation
Hi, I was discussing with some Mozillians at the MDN work week end and we were wondering how to keep track of changes in WebKit that require some documentation. For example, the Mozilla Bugzilla system has some keywords like dev-doc-needed and dev-doc-complete that MDN people can use to generate pages like https://developer.mozilla.org/en-US/docs/MDN/Doc_status/CSS so that people in charge of the documentation know what they must document or update. In particular, we mentioned the case of MathML in WebKit for which new attributes/elements are currently being implemented and the browser compatibility tables will need to be updated e.g. https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mo#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mspace#Browser_compatibility At the moment, I suggested to rely on the WebExposed keyword to find these kind of changes, but I'm not really sure what is the particular policy for that keyword to be set. For example, can I add this WebExposed keyword when I implement new MathML features? Other than MathML, are other new features systematically tagged with that keyword? Do you have any suggestion for Bugzilla parameters that could help MDN people (and that the administrator of WebKit Bugzilla should add if necessary)? For example a keyword similar to dev-doc-complete to indicate when the documentation is done or to target milestone to indicate in which Safari version the changes will happen? -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Tracking WebKit changes needed documentation
Thank you Ryosuke. So I'll tell the MDN people that they can use the WebExposed keyword and will use it myself when I add new features to WebKit. I think the best the MDN people can do for the browser compatibility table is to get the list of WebExposed bugs and check if they landed in the latest version of Safari. -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Anonymous style (inheritance and dynamic update)
Hi all, I'm trying to refactor the MathML code to follow what seems the clean way to add style to elements and prepare for future improvements. Hence I have tried to do some experiments with anonymous style and that seems to work in some cases, but sometimes the style is not applied correctly. I don't know much about the WebKit layout code and just tried to copy what was done elsewhere. So I would appreciate if someone more familiar with the code base could check if the code makes sense and suggest the right way to implement that otherwise? In https://bugs.webkit.org/show_bug.cgi?id=124838 I have attached a big patch that shares some code between the mi, mo and the mfenced elements (which uses anonymous mo), cleans up more things and tries to fix other rendering bugs. For convenience, I have extracted the changes that are only relevant to mi in a smaller patch: https://bug-124838-attachments.webkit.org/attachment.cgi?id=223101 (see in the new nsRenderMathMLToken class). The basic test case https://bug-44208-attachments.webkit.org/attachment.cgi?id=219653 renders correctly with that patch but as I said above, other reftests fail for some reason. Note that you don't need to know anything about MathML, but the following info might be helpful: 1) Single variables like mix/mi should be italic while multiple-char identifier like misin/mi should be upright ; the plan is thus to map this to CSS font-style (this is not quite what the MathML spec says but this approximation has been used in Gecko for a long time, so that's ok to use it in WebKit for now). Also in theory, whitespace should be collapsed in MathML tokens, so mi x/mi is equivalent to mix/mi. 2) Operators like mo+/mo or mo(/mo may have different spacing. The default being indicated by the operator dictionary (http://www.w3.org/TR/MathML3/appendixc.html). The idea is to map this to margin-left/margin-right. This is what I try to do in the bigger patch https://bug-124838-attachments.webkit.org/attachment.cgi?id=222977 as well as in the follow-up bug https://bugs.webkit.org/show_bug.cgi?id=99620. Thank you, -- Frédéric Wang MathML Crowdfunding: ulule.com/mathematics-ebooks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
